This is a excellent book that details a one-week work plan for a design sprint. While the idea of a design sprint isn’t new, I haven’t seen another book explain the concept as well or provide as much detail as this one. There is plenty of practical advice, including separate facilitator notes that are invaluable for someone who wants to run a design sprint for the first time.
Below are my notes that I took while I read the book and after doing a design sprint myself.
On Monday, the two most important outputs are the business goal and the sprint question. When I did this the first time through, we had a clear business goal, but a less-than-precise sprint question. It would have been better if we had a precise question to refer back to after the sprint was finished.
It is possible to do Wednesday through Thursday remotely, especially if the team members building the prototype are used to working remotely. It isn’t ideal, but it is possible if you don’t have the budget to keep everyone in the same room.
Overall, this process it very effective for getting a team that is running in different directions on the same page. It can be used to get a distributed team pulling in the same direction, and it is a good way to get contributions from team members that are typically very operational and less involved in the day-to-day creative process of building your company’s product.
If you went six months into the future, what would have improved about your business as a result of this project? It’s OK to be aspirational here.
Write the long-term goal on the whiteboard.
Next, ferret out the assumptions for this goal. If this project doesn’t succeed, what probably went wrong? To reach our long-term goal, what has to be true?
Rephrase assumptions as questions. Example assumption: “To reach new customers, they have to trust our expertise”; rephrased as a question: “Will new customers trust our expertise?”
Write sprint questions on the whiteboard.
Make a map of how people interact with your business. List the people on the left, and map out the actions and interactions that these people make with each other and your business. The right-most action should relate to your goal for the sprint (eg, “Buy” or “Sign Up”)
Draw map on the whiteboard
Next, interview experts. It’s suggested that you keep interviews to 30 minutes and ask questions like:
While you are interviewing, take notes in “How Might We” (HMW) format (eg: “How might we develop trust in our customers?”).
Finally, pick a target.
The decider should choose one target CUSTOMER and one target EVENT. One or more of the sprint questions should line up with the target.
For the demos, they can come from any industry or any product.
The sketches can be ugly, but words matter, so any copy on the sketch should be realistic.
The storyboard should start with an opening scene. Think about what customers are doing just before they interact with your product. Ideally your opening scene should place your product next to your competitors. If you are testing multiple solutions, your opening scene should pose your different solutions as different competitors.
Example opening scenes:
Storyboarding rule of thumb: each frame is one minute of your actual user test. Aim for fifteen frames.
The main purpose of Thursday is to build your prototype that you will user test. Some tips for creating a prototype:
Another good suggestion is to have a designated Writer: one person responsible for copy. If more than one person is a copywriter, the language won’t mesh well.
Friday is user interview day. Here’s some tips that I found useful for user interviews: