An introduction to Design Sprints

I used to work for a company that had massive onboarding issues, 60% of users who signed up never made a transaction. That was less than ideal and the head of product calculated that if we could address that problem, we would make a massive dent in our growth targets. It was a financial application and I identified from user research insights that one of the reasons people were signing up but not transacting was because the onboarding on the mobile app was significantly worse than on the desktop. Several teams were affected by onboarding; product, marketing, compliance, customer services and operations. To come up with a solution that addressed the problem sufficiently, all of these teams needed to come together to agree on a solution. I used a design sprint to help do that.
‍

So what is a design sprint?

It’s a structured, time-boxed process that allows a team to create, test and iterate on a solution within a short frame of time. They are used to solve complex problems and encourage collaboration and creativity among team members. Former Google Ventures design partner Jake Knapp devised the design sprint process for Google in 2010. He took inspiration from Google’s product development culture and IDEO’s design thinking workshops. Design sprints always involve defining the problem, ideating solutions, prototyping, user research and reviewing the output.
‍

When should you run design sprints?

Whenever is helpful. I run them when I have a client that has a tight timeline and a clear outcome e.g. building a new app. I’ve run them in the example where we had a big hairy problem and a lot of teams to coordinate but usually, I would recommend using one if:

• You have a complex problem that needs to be tackled in new ways
• You want to create a new (potentially disruptive) thing
• You want to test a new concept
• You want to figure out what features to prioritise
• You need to address a specific problem
  ‍

Who should be involved in a design sprint?
‍

Mandatory attendees

• Facilitator(s): Typically a designer
• Business representative: Someone who owns the perspective of the business; could be a product manager, head of product or subject matter expert for the problem space.
• Design representative: You’ll need someone who can prototype, and run user research such as a UX researcher, product designer, interaction designer, or design manager.
• Technical representative: Someone who can provide the engineering view of the world is helpful. They can provide historical context or technical constraints which help frame the problem and create the prototypes.
  ‍

Optional attendees

Anyone who will be impacted by the work being contemplated including but not limited to:

• Data analysts
• Testers / Quality Assurance
• Customer services
• Product managers or owners
• Scrum masters / Project managers
  ‍

How does a design sprint work?

Design sprints are typically run in five days. I think that a design sprint should match your organisation’s sprint cycle, so if you release something every week then five days makes sense but if you do it fortnightly, a two-week sprint is acceptable. There are five stages of the design sprint and I will go through them from the point of view of a five-day sprint.
‍

Day 1: Understand and define the problem

The purpose of this day is to go through any user research insights and agree on:

• an exact (singular) problem to be solved
• an outcome: how you will know it’s been solved
• some metrics that you can use to measure/track the outcome

People run this session with many tools and techniques. My favourite is the Lean UX canvas which provides a framework for exploring the problem space from a business and customer perspective.

For the earlier scenario, we agreed that we wanted to find out how to reduce the number of sign-ups that don’t result in a transaction without increasing the number of fraudulent transactions.
‍

Day 2: Sketch and ideate solutions

If day one went well, you should have a well-defined problem and can generate solution ideas. The key outcome of this day is a selection of great ideas that you think could be prototyped. You do that by starting with quantity and ending with quality.

My favourite way to run day two is in three parts:
‍

Ideation

• Individual ideation: People work alone and generate as many ideas as possible to solve the problem. My favourite tool to help here is crazy-8s.
• Pair ideation:Once people have generated at least 8 ideas each, they pair up and explain their ideas to someone else. Sometimes there are overlaps in ideas. Sometimes the pair ideates a bit further. In all cases, talking to someone else about your ideas always helps refine them.
  ‍

Grouping

Place the ideas on a board once you've talked through them. People should explain their ideas followed by the team groups overlapping ideas together.
‍

Voting

Once you've created groups, then everyone votes. I usually give people three votes each so they have to thoroughly evaluate each idea and only vote for the ones they are most excited about.

Other techniques for running day 2 include:

• Brainstorming
• Mind mapping
• Role-playing

‍

Day 3: Prototyping

Take the ideas that receive the most positivity or excitement into day three. Ideally, you, or the facilitator, choose a reasonable number of prototypes the designers can complete in one day.

I run this day in two halves. The first part of the day is for prototyping. Depending on how open your collaborators are and how complex the ideas are, you can prototype with them. I always make non-designers optional attendees for this day.

The second part of the day involves reviewing the prototypes with everyone to ensure that the mockups reflect the ideas properly and work as expected. Leave enough time for changes especially if the designers worked alone.

Your outcome for the day is a prototype or prototypes to evaluate with users and create a rough user research plan for that testing.
‍

Day 4: User research

This is potentially my favourite day of the design sprint because it’s a chance to get your real prospects or customers testing out the prototypes. A few guidelines for the research:

• Make sure you have a clear plan. Ideally, your plan is focused on the problem. For my plan in the example above, our research goal was to understand which prototypes made it more likely for the user to proceed to their first transaction.
• Match the number of people in the research to the number of prototypes. You can imagine it's easy to review three prototypes with five people. It's more tricky to do so with 15 prototypes. You might need 15 users to review five prototypes each.
• Structure the day so that you can make improvements. Given that you usually have conceptual prototypes for this kind of research, it might be necessary to test variations and make improvements iteratively to nail down a desirable version of your prototype.
• Get non-designers to watch the research. People often underestimate the power of user research so get as many people involved in the sessions as possible. I’ve found that people are more interested if their ideas are being tested.
  ‍

Day 5: Review and plan

The main goal of the final day is to end up with a clear answer to the question “what next?”

• Start with a recap of the findings from user research. You might not have had enough time to do an in-depth analysis but you should be able to walk through the findings. Reveal prototypes that were successful or otherwise against the metrics and share any recurring themes that came through in the session.
• Agree on a winner/winning direction. As long as you didn’t test only one prototype, there should be aspects/features or prototypes that resonated with your users. Get the group to acknowledge which ones they were.
• Discuss a potential development plan. Many things would have to be true to move a conceptual prototype into a feature or product for your team. What are those things? Try to list them out and agree on a rough timeline for the next step. For my example scenario, we were able to focus on a prototype that improved the onboarding steps within iOS and Android apps and agree on the following: Designers to build out an end-to-end prototype of the concept, usability testing, build on iOS, test with New Zealand users (a small isolated set of customers with a high potential for improvement) and finally, track against the metrics agreed on day one. In our case, our North star metrics were number of fraudulent transactions and transactions within seven days of sign-up
  ‍

Wrap up

So, there you have it. You now have a breakdown of what a design sprint is, when to use it and how you might run it. What do you think? Tell me how you’ve run yours if you do it differently and if you haven’t, are you going to give it a go?

‍