Some background
In the last few years, Merck has hired more developers in several offices around the world and adopted newer web and mobile technologies. Because of this, they realized that their developers had a huge amount of combined knowledge, most of which was contained in silos. Many people weren’t tapping into the expertise or knowledge of others within the company, or were only using personal networks to get access to isolated knowledge.
Merck wanted to build a community around their developers in order to make sharing knowledge easy and a less isolated process. From a business standpoint, the company realized the impact this might have in saving their developers’ time, as well as increasing the skill level across development languages and roles enabling their employees to learn and their teams to be more flexible.
Design Sprints
We kicked off the project with two design sprints. During the first sprint, we both validated and invalidated some of the features when testing the prototype. After reviewing all of our notes at the end of the sprint, we decided it would be best to conduct another design sprint to build upon what we learned from the first sprint.
After the second sprint, we felt more confident in our solution for the problem. We started building a product focusing on duplicating the social events that were already happening around the company and enhancing them. We gathered together the main categories of conversations that employees were having and sought to amplify them. These became our post types and allowed us to better deliver content that was interesting to each individual user.
Using Jobs-to-be-done
The core product team was small, consisting of one designer and developer from thoughtbot as well as one Product Manager on the client team. This allowed us to move fast and test the application more iteratively. It also allowed for less overhead communication and led to more fruitful conversations in-person as well as on Trello and Slack.
These conversations where enhanced by using job stories. Jobs stories allowed us to concentrate on the users’ needs instead of a specific feature set. Because we used jobs stories, our team was more empathetic to our users.
Jobs story format
As a [persona/role] I want to [action] so that [outcome/benefit].
Usability Tests and Interviews
Halfway through the project, we noticed during usability testing that there were remaining problems with our post categories. The differences still weren’t clear to some of our users. We gathered together for one last quick design sprint, which lasted one day. During the sprint we formulated a plan to refine the implementation and make it clear to all of the users what the post types were. We again prototyped and tested our new assumptions. This time we had much more success, and it the intention seemed clear to our users.
We continued to interview Merck developers, using jobs-to-be-done style interviews, throughout the lifetime of the project. During the interviews, we would ask them about how they use other tools online to validate whether the application was something they would continue to use over time. We asked them to use the application as we were building it in order to best continually test new features. This helped us target the core of the product and refine the user experience of the main feature set.
We added some personality to the application by adding animated gifs in the least likely of places. This made the platform more fun and engaging and not just another forum.
The Merck team launched the product towards the end of our eight week engagement to a select group of users to begin populating the community with discussions.
