We recently completed a four-day product design sprint with Merck. They are actively building their development team and looking for a central place to share Merck specific development knowledge and tools. There is a potential for aspects like APIs, code snippets, and general procedural knowledge to be shared, thereby saving the company developer time and money. Their hope is to encourage developers to more readily share their knowledge and code across teams and contents.
Day One – Understand, Diverge
Since the team had only a general idea of what to build, we ran a number of activities to better understand what problems this project should solve. We played Who, What, Where, When, 5 Whys and completed a card sorting exercise. We ran these activities to refine the goal for the project and what would make it successful.
These games nurtured a healthy debate on whether the application’s primary job to be done was to share code and knowledge among developers or if the priority was to show how much money is being saved with code reuse for managers. The assumption was that if managers have buy in, they would force developers to use the application. If we got developers interested, the application would encourage education and reuse of code. We would be able to calculate financial savings later.
We decided that the primary job was to spread knowledge and code, and that quantifying time and money savings would eventually grow from this primary goal. We recorded the conflict so we could return to it later, if necessary.
After starting mind maps, crazy eights and storyboards, the debate resurfaced regarding the primary problem we were trying to solve. Because it was later in the day, I recorded a new challenge statement to address the contrarian thought and suggested that everyone break early to contemplate the issue overnight, individually. My intention for taking a step back from the project was that it would allow the team to return refreshed the following day.
Day Two – Diverge, Converge
The following morning, we dove back in. We briefly discussed our two problem statements, and how this major conflict and assumptions would be a highlight of our user interviews and problem / solution tests. Together we converged on a third and final challenge statement, which was both shorter and simpler than the first two.
Make it easy to share development work and knowledge at Merck to spread knowledge, save developer time and resources and quantify that savings.
We reflected on the critical path that we were following with the first statement and analyzed the similarities and potential differences that this new challenge statement introduced. We examined the storyboards that we completed the prior day and found that much of our previous work would carry over nicely to our new statement.
Despite our progress, there was one thing that I felt was holding us back. It wasn’t clear to me what Merck wanted developers to share, and what form this would take and whether developers would want to share it. We completed another card sorting exercise to organize the team’s thoughts about the types of posts and content they sought. We organized them based on what we felt was most important.
Now with a clear goal and a better understanding, we completed several more rounds of mind maps, crazy 8s and storyboards. With each round we slowly reached a consensus on what the user flow would be for each of the steps in our critical path. At the end of each round, we reflected back to our challenge statement to make sure that we were still on track.
Because we had completed so many group exercises, developing the layout of each page went relatively smoothly and quickly. We wireframed each screen on a whiteboard based on the sketching we had completed in previous storyboards. We then listed the assumptions we had been making throughout the two days and drew conclusions regarding which aspects we should try to validate with some user research before the user interviews and problem / solution tests.
Day 3 – Prototype
I spent the entire day creating a prototype using Sketch and Invision. I was easily able to recreate our whiteboard wireframes in Sketch and place the exported files into a folder to be synced. The primary issue that I had with Invision was the lack of support for any kind of form input. It was also time-consuming to design states for buttons and form inputs for each wireframe.
Day 4 – Test
User interview and testing proved very useful. We both validated and invalidated a majority of our assumptions about developers at Merck and what our application would accomplish. We learned that developers were already sharing a lot of code and knowledge within Merck through their personal network. The longer that the developer had been with Merck, the more they had shared, and the more knowledgeable they were about who they considered experts in particular fields.
Outside of the company, however, most developers were not participating in online discussions, blogs or forums. This was one of our key indicators on whether they might be willing to contribute within the company. The user interviews and problem / solution tests did identify some problems and invalidated some assumptions that we had. Users weren’t clear on the types of posts that they could make, and the barrier for entry was a lot higher than we previously thought.
Design Sprint Wrap-up
In the end, we didn’t feel strongly enough that the solution we created in the prototype would be worth the time to build as it was. By testing out the quick prototype we saved Merck several weeks of development in the wrong direction. After some discussion, we agreed to do another shortened sprint to tackle the problems we found with the last prototype. This way we could continue to refine some of the ideas that came out of our diverge sessions on day one and two with the new found information from testing.
