Where it came from
Born at Google Ventures.
Refined for the real world.
Jake Knapp developed the Design Sprint at Google, and GV codified it into a 5-day format used by hundreds of startups and enterprise teams. We run a condensed 2-day version — same rigorous phases, tighter execution, designed for teams that can't disappear for a week.
Original format
5
The original GV sprint runs Monday through Friday: understand, define, sketch, prototype, and test — one phase per day, with a full working prototype ready by Friday morning for user testing.
Our format
2
We compress phases 1–3 into Day 1 and hand off to a dedicated design team overnight. Day 2 opens with a prototype preview and closes with a live research debrief. Teams leave with validated direction — not hypotheses.
Why it works
Sprints force decisions by constraining time. The pressure of a real deadline — "we test this prototype tomorrow" — eliminates opinion-based debates and replaces them with evidence. You learn more in 2 days of structured work than in 2 months of meetings.
What you leave with
- A tested prototype (not a wireframe — a realistic artifact)
- User feedback from real research sessions
- A validated (or invalidated) hypothesis
- A clear recommendation on next steps
The five phases
Every sprint moves through
the same five phases.
The phases aren't suggestions — they're the engine. Skip one and you lose the momentum that makes sprints work. Each phase has a specific output that feeds the next.
morning
Understand
Empathy · Expert knowledge · HMW notes
The team surfaces everything they know — and everything they don't. Expert talks from internal SMEs, review of existing research, and customer data give everyone a shared foundation. Individual "How Might We" notes capture problems worth solving without jumping to solutions.
Output: HMW note set + shared problem understandingmidday
Map
Journey · Target moment · Decision
The team builds a shared journey map of the user experience, end to end. Then — critically — identifies the single most important moment to focus the sprint on. The Decider makes the call. This narrows the entire sprint to one high-leverage target, preventing the diffusion that kills most design efforts.
Output: Journey map + target sprint momentafternoon
Sketch
Lightning demos · Individual sketching · Dot voting
Individuals — not groups — sketch competing solutions independently. No group brainstorming, no loudest-voice-wins dynamics. Lightning Demos from analogous industries spark ideas. The 4-step sketch method produces detailed, structured concepts. Dot voting and the Decider's final call pick the winning direction before Day 1 closes.
Output: Winning concept sketch + storyboardmorning
Prototype
Design team build · Sprint team prep · Preview
Overnight, the storyboard is handed to the design team who builds a realistic — not pixel-perfect — prototype. The bar is just high enough that users can give genuine reactions. While designers work, the sprint team prepares research questions and interview guides. By midday on Day 2, the prototype is ready for preview and final review.
Output: Testable prototype (Figma / interactive)afternoon
Test
User feedback · Insight synthesis · Verdict
Research sessions run in real time — the sprint team watches, notes patterns, and identifies the moments where users succeed or struggle. The facilitated debrief surfaces the top 3 insights, evaluates the hypothesis, and produces a clear recommendation: iterate, pivot, or proceed. You leave Day 2 knowing — not guessing.
Output: Insights + hypothesis verdict + recommendationOur 2-day model
How five phases fit
into two days.
The 2-day model works because prototype production is parallel, not sequential. While designers build overnight, the sprint team prepares. Day 2 is about testing and deciding — not catching up.
Welcome & norms
Team intros, sprint rules, agenda
Understand
Expert talks, HMW notes, existing research
Map
Journey mapping, target moment selection
Lunch
Working lunch — informal synthesis
Sketch
Lightning Demos, 4-step sketch, dot vote
Align & Decide
Decider selects direction
Storyboard
Panel-by-panel prototype brief
Hand-off to design team
Storyboard + brief delivered for overnight build
Design team: prototype build
Parallel session — sprint team not present
Sprint team: research prep
Interview guide, discussion questions, observation plan
Lunch
Prototype preview — team reviews with design team
Prototype finalized
Sprint team walk-through and sign-off
Research debrief prep
Observation notes, pattern spotting
Reconnect: insights review
Top 3 insights, hypothesis verdict, recommendation
Retrospective
What worked, what to take forward
Close + next steps
Readout timeline, owner assignments
Who's in the room
Six roles that make
a sprint function.
Sprints fail when the wrong people are in the room — or the right people aren't. Each role has a specific job to do. Understand which one you are before Day 1.
Facilitator
Process owner
Owns the agenda, keeps time, and ensures the process is followed without influencing content. Steps in when the group stalls, calls votes, and protects the Decider's role. Does not sketch or vote on solutions.
Decider
Decision authority
Makes the final call at every key decision point: target moment selection, concept direction, go/no-go at the end. One person, one vote that overrules all others. Usually the product leader or business owner accountable for the outcome.
Lead SME
Domain expert
Delivers the expert talk during Understand. Answers deep domain questions the team needs to move forward — technical constraints, regulatory context, customer behavior. The team's primary source of domain truth during Day 1.
Sprint Team
Cross-functional contributors
3–6 people from different functions — design, engineering, research, marketing, operations. They sketch, vote, and challenge assumptions. Diversity of perspective is the point: someone who knows what's buildable, someone who knows the user, someone who knows the business.
Prototype Owner
Design team lead
Receives the storyboard at the end of Day 1 and leads the overnight prototype build. Sets scope for what's buildable by midday Day 2, manages design team execution, and presents the prototype to the sprint team at the Day 2 preview.
Researcher
User feedback lead
Designs and runs the research sessions on Day 2. Recruits participants, prepares the discussion guide with the sprint team, moderates sessions, and synthesizes findings for the reconnect debrief. The research quality determines the quality of the recommendation.
When to sprint
Not every problem needs
a sprint. These ones do.
A design sprint is the right tool when you have a real problem, genuine uncertainty about the solution, and enough stakeholder alignment to act on what you learn. These four scenarios are the clearest signals.
Known problem, unknown solution
You have clear evidence of user friction, drop-off, or failure — but no validated idea for how to fix it. The sprint generates and tests multiple approaches in 48 hours instead of months of iteration.
A metric that's consistently off
Conversion, retention, activation, satisfaction — something is measurably wrong and the team disagrees on root cause. A sprint structures the problem before jumping to solutions.
Business-pressured decision
A competitive threat, market shift, or leadership mandate is forcing a product decision faster than the normal process allows. A sprint compresses discovery and validation into one focused event.
Suspected outcome that isn't landing
You shipped something and the expected behavior didn't follow. Users aren't doing what you designed for. A sprint reframes the problem and tests a new hypothesis without a full rebuild cycle.
"The sprint isn't for every problem — it's for the problems where the cost of guessing wrong is too high to afford another quarter of iteration."
When not to sprint
Too big
Platform redesigns
A sprint can't validate a strategy — only a specific, scoped experience. If you can't identify a single user moment to prototype, the problem needs to be narrowed first.
Too small
Copy changes · A/B tests
Incremental optimizations don't need two days and a cross-functional team. Save sprint bandwidth for genuine uncertainty, not tweaks that can be shipped and measured directly.
Wrong type
Technical architecture
Design Sprints test user-facing hypotheses, not technical ones. If the core question is about system design, scalability, or data architecture, a different process is the right tool.
What you leave with
Five artifacts. Two days.
A sprint produces real, actionable artifacts — not presentations about what to build next. Every output maps directly to a decision or a next step.
Problem statement
A crisp, agreed-upon framing of the challenge — written by the team, validated by the Decider.
Journey & target moment
A user journey map with one specific moment selected as the focus for the entire sprint effort.
Winning concept
The selected solution sketch and a storyboard — the brief that drives the overnight prototype build.
Testable prototype
A realistic, interactive artifact built by the design team — real enough to generate honest user reactions.
Research insights + recommendation
Top 3 insights from user sessions, a hypothesis verdict (validated / partially / invalidated), and a clear go/no-go/pivot recommendation with rationale.
Module 2 — Intake
Ready to propose a sprint?
The Sprint Intake Form walks you through problem framing, evidence gathering, stakeholder setup, and an entry criteria check — ending with a scored readiness assessment and a ready-to-share brief.