Design Sprints: Accelerating the Product Development Process
Wouldn't it be great to know that the product you design would be loved by users, before you spent time developing and launching it? Companies often invest long periods of time on product design, only to find that the product is not exactly what the user wanted. The product revision process ensues, reacquiring users and helping them overcome the faults of the first release, to give the updated product a second chance. This all leads to a waste of time and precious resources.
This is where the Design Sprint comes in. The Design Sprint, developed at GV by design partner Jake Knapp, is a five day process of identifying key business problems to solve, generating solutions, and testing a prototype with users. The Design Sprint allows you to accelerate learning by maximizing solutions to test, and minimizing time spent on unknown options.
In early March, Omidyar Network and Women In Product (WIP) hosted a workshop on Immersive Design Sprint for Product Leaders. Ashita Achuthan (WIP co-founder) and Ha Nguyen (Omidyar Network) led this interactive workshop and provided summarized instructions on how to run your own Design Sprint.
Here are the takeaways:
What is a Design Sprint? The process of understanding the user’s needs before designing and validating solutions to address that need in a structured, five day process.
When should this process be used?
- When there is limited time in which to gain answers and results
- When there is lack of alignment within the team, and people have varying ideas of how to solve the problem
- When the problem to solve is complex, with many unknowns
Who should be involved?
It is important to recruit the right team members in order to have contributions to problem solving, decision making, and buy-in of the solution.
Ideally the team consists of 6–8 people that includes Product, Design, and Engineering. Sprint teams can also include cross-functional representation from Customer Service, Sales, or Marketing.
- Project sponsor aka “The Decider” — final decision maker
- Product owner
- Technical or logistical advisor
- Customer advisor
- Design advisor
- Prototyper
- Marketing/PR advisor
Two of the most important roles on the sprint team are The Decider and The Facilitator. These should not be the same person. The Facilitator is responsible for making sure that the team is on track from a schedule perspective and also helps with the tactical details like booking conference rooms, capturing notes, and guiding the conversation.
How does it work? — Design Sprint Process:
Day One: Map the Problem
The goal of this day is to come up with the sprint challenge statement. Talk to one person at a time and capture notes. Some questions to help with identifying the right problem:
- Who is the target user?
- What is the problem that we are trying to solve?
- What benefit will our product provide to the user?
Day Two: Ideation
The goal of this day is to come up with one solution sketch that will best address the problem identified on Day 1.
- Crazy 8’s — Generate multiple ideas to solve the problem, so there is a variety of options from which to choose. Each person folds a sheet of paper into eight sections and sketches their best ideas in each section (~1 min per section). The sketches are displayed and each participant is asked to do a silent review of the sketches. Each person then puts a sticky dot next to the ideas that they like. Finally, the team speed critiques the ideas with the most votes. Invite those who voted to share why they liked an idea. At the end, the author will reveal themselves.
- Solution sketch — The goal is to take the ideas that have been generated and sketch an actual UI showing how a user would move through the solution — where they click, what info they enter, and so forth. Taking a couple of ideas generated from the Crazy 8’s process, draw out a user interface in three frames to show a user’s progression from step one to step three. Then, repeat the process of speed critiquing, to identify the solution/s to carry forth.
- In some cases, there will two or three solution sketches that come out of day two if ‘The Decider’ chooses to carry forward a couple of options.
Day Three: Storyboard
The goal of this day is to advance the winning solution sketches into a storyboard and flesh out the details.
After the speed critiques from the Solution Sketches in day two, vote on the solution sketches that you like best. After voting, ask ‘The Decider’ to pick a solution to move forward with. Break into small groups to storyboard the solution, adding more detail. Have teams present these storyboards to each other at the end of the day.
‘The Decider’ will choose the storyboard that will ultimately be taken forward.
Day Four: Prototype
- Design — This requires building a prototype of the chosen solution, a simulation of the solution that will be put in front of customers. For a web or mobile app, it often involves creating mock-ups that are clickable through a prototyping tool, such as Sketch or Invision.
- Prepare questions for user interviews
Day Five: User Validation
After building a prototype, you’ll interview target customers and gain insights through their reactions. At the end of the day, you’ll know how far you have to go, and the next steps. You’ll want to schedule five to seven customer interviews and watch them interact with their prototype. When conducting user validations:
- Target five users in individual sessions. Try and go to their environment, this fosters honest feedback
- Watch where the user is getting stuck with the prototype — probe to understand but don’t help them navigate through.
- Note the customer response to gauge how valuable this product is to them. Here are some questions to help understand what the customer truly feels about the product:
- How much would you be willing to pay for this product?
- Would you be willing to coming to the office in two weeks to test the actual product and give us feedback? Willingness to bring a friend?
- If NPS score is not 10, what would get this product to a 10?
What’s next?
Here are some possible outcomes from the Sprint:
- Successfully validated — about 20% of the time your solution is ready to proceed to engineering as is
- Partially validated — 70% — the solution needs tweaks
- Invalidated — 10% — the right solution has not yet been found. Based on the invalidity of this solution, further thinking around the problem is required.
The Design Sprint provides a framework for tackling challenging problems but it can be tailored to meet your needs.
Thinking about conducting your own Design Sprint?
Here are some resources:
- Design Sprint Workshop — Powerpoint presentation
- Here are some shorter Design Sprint agenda samples: 1 day , 2 day
- Google developers Design Sprint Playbook: Design Sprint Playbook
