Run Design Sprint

---
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

1. **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.
2. **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.
3. **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.
4. **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.
5. **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.
6. **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.
7. **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.