In one minute
Timebox a difficult product question, build a realistic prototype and learn from users before committing.
Move through understanding, defining, sketching, deciding, prototyping and validation. A sprint is a bounded learning event; user responses and safeguards determine what happens next.
The problem it addresses
A team debates a risky concept for months without showing anyone a testable version.
A city considers a complex disaster-alert app. Residents currently miss evacuation instructions when messages use unfamiliar landmarks.
When to use it
- Use Design Sprint when a team debates a risky concept for months without showing anyone a testable version.
- The team can examine: A narrow challenge, decision maker, customer access, facilitator and time for prototype testing.
- A relevant situation is: A city considers a complex disaster-alert app. Residents currently miss evacuation instructions when messages use unfamiliar landmarks.
When not to use it
Do not use it to replace evidence, accountable judgement or affected people's participation.
Using a polished prototype to sell a chosen solution or treating five interviews as statistical proof.
Inputs required
A narrow challenge, decision maker, customer access, facilitator and time for prototype testing.
Step-by-step process
1. Bound the decision and name its owner.
Write the scope, decision owner and people who can veto or revise the result before starting the workshop.
2. Collect the necessary evidence and affected perspectives.
Collect and date the necessary evidence: A narrow challenge, decision maker, customer access, facilitator and time for prototype testing.
3. Frame one high-stakes question and the decision it informs.
Record the evidence and decision criterion for: Frame one high-stakes question and the decision it informs.
4. Gather evidence and sketch several different approaches individually.
Record the evidence and decision criterion for: Gather evidence and sketch several different approaches individually.
5. Choose a testable direction with a recorded decision rationale.
Record the evidence and decision criterion for: Choose a testable direction with a recorded decision rationale.
6. Prototype only the interaction needed to test the critical assumption.
Record the evidence and decision criterion for: Prototype only the interaction needed to test the critical assumption.
7. Observe representative users, synthesise disagreement and choose the next test.
Record the evidence and decision criterion for: Observe representative users, synthesise disagreement and choose the next test.
8. Record the output, next test and review trigger.
Store the artifact with its evidence links, owner, bounded next test and date or trigger for review.
AI automation lens
AI may sort authorised notes and expose missing evidence. It must not invent observations, silently decide for affected people or present a generated map as validated.
Visual model
Text alternative: Frame one high-stakes question and the decision it informs; Gather evidence and sketch several different approaches individually; Choose a testable direction with a recorded decision rationale; Prototype only the interaction needed to test the critical assumption; Observe representative users, synthesise disagreement and choose the next test.
Interactive example
Scenario: A city considers a complex disaster-alert app. Residents currently miss evacuation instructions when messages use unfamiliar landmarks.
Worked answer: Prototype two short alert formats with accessible landmarks, test comprehension with residents and emergency staff, then decide whether an app is needed.
Facilitation notes
Record disagreements before synthesising; ask whose evidence is missing; state who may revise the result.
Expected output
- An inspectable decision artifact, its assumptions and evidence, a responsible owner, a bounded next test and a review date.
- Observe representative users, synthesise disagreement and choose the next test.
- A named owner, test and review date.
Common mistakes
Using a polished prototype to sell a chosen solution or treating five interviews as statistical proof.
Quality checklist
- The decision and system boundary are explicit.
- Affected people and alternative accounts are included.
- Each important claim has a source or is marked as an assumption.
- An owner, safeguard and disconfirming signal are named.
Template
Knowledge check
Question: What mistake would undermine this method in the scenario?
Answer: Using a polished prototype to sell a chosen solution or treating five interviews as statistical proof.
Related tools
References
- Design Sprint — method source (opens in a new tab). Accessed 2026-10-09.
- Further practice reference (opens in a new tab). Accessed 2026-10-09.
Method profile
The method structures a discussion and a test; it does not establish causal proof or guarantee success.