The design sprint process: what it is and when to run one
The short answer
A design sprint is a five-day process, developed at Google Ventures and described by Jake Knapp in the book Sprint, that takes a small team from a problem to a prototype tested with real customers in one week. It works best for one clear, high-stakes question that the team already understands. It is the wrong tool when the problem itself is still unclear or when the work is a large system.
What is a design sprint?
A design sprint is a fixed, five-day process for answering one important product question by building a realistic prototype and testing it with real customers. It was developed at Google Ventures and described by Jake Knapp, with John Zeratsky and Braden Kowitz, in the book Sprint. Instead of debating an idea for months, or building it before anyone outside the team has seen it, a small group spends one week mapping the problem, sketching options, choosing one, prototyping it and watching customers use it.
The output of a sprint is not a finished product. It is evidence. At the end of the week the team knows whether the direction works, which parts confuse people and what to do next.
What happens on each day of a design sprint?
Each day of a design sprint has one goal and one output, and each day starts from the output of the day before. The table below is the standard five-day format.
| Day | Goal | Output |
|---|---|---|
| Monday: Map | Understand the problem and choose a target | A map of how customers move through the product and one target moment to focus on |
| Tuesday: Sketch | Generate solutions | Detailed solution sketches, each made by one person working alone |
| Wednesday: Decide | Choose one solution | A storyboard that plans the prototype step by step |
| Thursday: Prototype | Build something that looks real | A realistic prototype and an interview script |
| Friday: Test | Watch customers use it | Interview notes, patterns across interviews and a decision on next steps |
Monday: map the problem
The team agrees on a long-term goal, writes down the questions that could make the project fail, and draws a simple map of the steps a customer takes. In the afternoon, people in the company who know the problem well, such as support staff or engineers, are interviewed briefly. The day ends with the Decider choosing one target on the map.
Tuesday: sketch solutions
The team reviews existing ideas from competitors, other industries and the company's own past work. Then each person sketches a full solution alone, on paper, in a few steps. Working alone produces more distinct options than a group brainstorm, where the loudest idea tends to win.
Wednesday: decide
The sketches go on the wall. The team reads them in silence, marks the parts they like, discusses briefly and votes. The Decider makes the final call. In the afternoon the team turns the chosen sketch into a storyboard: every screen or step the prototype needs, in order.
Thursday: prototype
The team builds a prototype that is real enough for customers to react to it honestly. For software this is usually a clickable prototype in Figma. It only needs the screens in the storyboard, not a working back end. Someone also confirms the test participants and writes the interview script.
Friday: test
One person interviews customers one at a time while they use the prototype, and the rest of the team watches from another room and notes what they see. The book recommends five interviews. By the end of the day the team can see patterns: what worked, what failed, and what to change.
Who should be in the room for a design sprint?
A design sprint needs one person who can make the decision, one person who runs the process, and a few people who know the problem from different sides. The book recommends seven people or fewer. A typical team looks like this:
- Decider: the founder, product lead or executive who owns the outcome and can say yes or no.
- Facilitator: runs the schedule, keeps time and keeps discussions short. This is often us.
- Designer: turns sketches and the storyboard into the prototype.
- Engineer: knows what is possible and what it will cost to build.
- Someone who talks to customers: from sales, support or operations.
- Someone who knows the business: pricing, costs, marketing or legal constraints.
Everyone needs to clear their calendar for the week. A sprint where people leave for other meetings produces weaker decisions, and a sprint without the Decider on Monday and Wednesday usually ends with a direction that gets changed later.
When is a design sprint the right tool?
A design sprint is the right tool when you have one specific, high-stakes question, enough knowledge of your users to frame it, and a decision that would be expensive to get wrong. Common examples:
- A new product or feature concept, before engineering time is spent on it.
- A key flow, such as sign-up or checkout, where you already know people drop off but not why.
- Two competing directions for the same screen or flow, and a team that cannot agree.
- A team that has discussed the same problem for months without a decision.
When is a design sprint the wrong tool?
A design sprint is the wrong tool when the team does not yet understand the problem, or when the work is too large to test in a single prototype. The cases we see most often:
- The problem is not understood yet. If the team cannot say who the users are and what they struggle with, the sprint will test guesses. Start with user research, then run a sprint on what you learn.
- The work is a large system. A SaaS platform with many roles, screens and states, or a design system, cannot be decided in one week. A sprint can answer one question inside that project, but it does not replace the project.
- The answer is already clear. If the evidence already points one way, build it and measure.
- The problem is small. Fixing one screen or one label does not need six people for five days.
- No one can decide. Without a Decider in the room, the sprint produces options, not a decision.
How do we adapt the design sprint process?
We change the length and format of a sprint to fit the question, but we keep the order of the steps: understand, sketch, decide, prototype, test. The adaptations we use most:
- Shorter: when earlier research has already mapped the problem, we combine the map and sketch days and run the sprint in four days.
- Longer: when the prototype needs more detail, or the participants are hard to recruit, such as operations staff for a B2B tool, we spread the prototype and the tests over a second week.
- Remote: we use a shared FigJam board, keep sessions shorter with breaks in between, keep the silent individual work, and run the customer tests remotely in Maze or over video calls.
- Bilingual: when the product is used in English and Arabic, we test each participant in the language they use every day.
A sprint is a compressed version of how we work on every project. Our process runs Understand, Design, Test and Build, and a sprint covers the first three steps in one week.
What happens after a design sprint?
After a design sprint the team makes one of three choices: build the direction, change it and test again, or drop it. A sprint prototype is not production design. It covers the main path only, so the next step is designing the full product: every state, edge case and error, on a design system the engineers can build from. If you have a question that fits a sprint, or you are not sure it does, tell us about it.
Sources
Related services
