| name | run-design-sprint |
| description | Use when a product team needs to answer a critical design or business question through rapid prototyping and user testing in one week |
| source | Jake Knapp, John Zeratsky, Braden Kowitz "Sprint" (2016); Google Ventures Design Sprint methodology |
| tags | ["design-sprint","product-design","prototyping","user-research","innovation","team-facilitation"] |
| verified | true |
Run Design Sprint
Compress months of design-build-test cycles into five focused days to answer a high-stakes product question.
Why This Is Best Practice
Adopted by: Google Ventures (ran 150+ sprints with portfolio companies), Slack, Airbnb, LEGO, and adopted by NHS and UN for service design
Impact: GV data shows design sprints reduce average time to validated prototype from 6–12 weeks to 5 days; Knapp reports 85% of sprint teams make a major strategic decision based on Day 5 test results
Why best: A sprint forces the team to make decisions with incomplete information by creating real user data on Friday. It replaces weeks of debate and assumption with a concrete test result.
Steps
- Monday — Map and target — Draw the problem as a journey map from user to goal. Interview experts (engineering, sales, support, data). At the end of the day, vote on the long-term goal and the most critical point to focus the sprint on.
- Monday — How Might We notes — Throughout interviews, each participant writes "How Might We…" prompts on sticky notes. Cluster and vote to surface the team's shared priorities.
- Tuesday — Sketch solutions — Each person independently sketches 3–8 solution ideas using the "Crazy 8s" exercise (8 frames, 8 minutes). No group ideation — individual sketching produces more diverse ideas.
- Wednesday — Decide — Use the "sticky vote" method to evaluate sketches without discussion first. The Decider makes the final call on which solution to prototype. Storyboard the prototype in 8–12 frames.
- Thursday — Prototype — Build a facade (not functional code) using Keynote, Figma, or paper. Divide roles: maker, writer, asset collector, interviewer preparer. The prototype only needs to test the critical question — it does not need to be complete.
- Friday — Test — Run 5 back-to-back user interviews against the prototype using the think-aloud protocol. Observers watch in a separate room, noting patterns on sticky notes in real time.
- Friday — Synthesize — After interviews, identify patterns across 5 users. Decide: proceed as prototyped, iterate, or pivot. Document the decision and evidence in a one-page sprint report.
Rules
- Maximum 7 people in the sprint room. More than 7 slows every decision.
- No laptops during activities — phones and email are out during sprint hours (9 AM–5 PM).
- The Decider (usually a product leader) has final say on all votes; sprints are not democracies.
- The prototype is not code — never write production code during a sprint.
- Friday's test result is a signal, not a verdict; 5 users reveal patterns, not statistical significance.
Examples
Slack used a sprint to test whether users would understand a "Shared Channels" concept before building it. Day 5 tests with 5 users showed 3 of 5 were confused by the metaphor but loved the core idea. The team rebuilt the mental model (renamed, reframed) before writing a line of code.
Common Mistakes
- No clear Decider — Without a designated decision-maker, "sticky vote" results get relitigated; the sprint stalls.
- Building real code Thursday — Engineering sprints that build working software miss the point; a Keynote prototype tests the idea 10× faster.
- Recruiting wrong participants — Testing with colleagues or non-representative users produces invalid signal; recruit screened participants matching the target persona.
When NOT to Use
- Do not run a design sprint when the critical question has already been answered by existing user research or live product data — a sprint adds cost without new signal.
- Do not use a design sprint for execution work where the solution is already decided and the team needs to build, not explore — a sprint is a decision tool, not a delivery tool.
- Do not run a sprint when the Decider (a senior product or business leader with authority to commit) cannot be present all five days — without decision authority in the room, the sprint's outputs become recommendations that get relitigated after Friday.
