Design Sprints

The full lesson

When a product team hits a high-stakes design problem — a new market entry, a broken onboarding flow, a bet-the-company feature — the instinct is to plan a months-long discovery phase. Design sprints offer a sharper alternative. You compress the entire define-ideate-prototype-test cycle into one calendar week, walk out with a concrete answer, and do it all with the people who actually make decisions. That compression is not a shortcut. It is a deliberate forcing function that trades open-ended exploration for focused momentum and fast evidence.

What a Design Sprint Is

A design sprint is a structured, five-day process for answering one critical business or design question through prototyping and user testing. Google Ventures (now GV) developed the format, and Jake Knapp, John Zeratsky, and Braden Kowitz documented it in their 2016 book Sprint. The original structure maps each day to a phase: Monday for understanding and goal-setting, Tuesday for ideation, Wednesday for decision-making, Thursday for prototyping, and Friday for testing with five users.

The defining feature of a sprint is that it ends with behavioral evidence, not opinions. By Friday afternoon, your team has watched real users interact with a realistic prototype. You can make an informed go/no-go decision based on what you saw. That concrete output is what separates a sprint from a brainstorm, an offsite, or a discovery workshop — all of which generate ideas but rarely produce testable evidence within the same week.

The Five-Day Structure

The canonical GV sprint is still the best reference model, though most teams adapt it to their context.

Monday: Map and Pick a Target

The team builds a shared understanding of the problem by hearing from internal experts — customer support, engineering, legal, sales, domain specialists. During these structured sessions, everyone takes notes using a technique called “How Might We” (short questions that frame problems as opportunities). By end of day, the team maps the user journey, circles the most critical moment to focus on (the sprint target), and writes down a long-term goal plus the questions that could cause the sprint to fail.

Key artifacts from Monday: a journey map with the sprint target circled, organized “How Might We” notes, a long-term goal statement, and a list of sprint questions.

Tuesday: Sketch Solutions

Each team member independently reviews competitive examples and analogous inspiration. Then each person sketches a detailed solution on their own. The sketching follows a four-step progression: notes, rough doodles, a concept sketch, and a final detailed sketch.

Because everyone sketches individually before any group discussion, Tuesday produces genuine solution diversity and avoids groupthink. This matters: in a typical brainstorm, the loudest voice wins, people anchor on the first idea, and junior team members defer to senior ones. Individual sketching removes all of that.

The key rule: solutions are drawn, not talked through.

Wednesday: Decide and Storyboard

The team reviews all sketches silently and uses a structured “sticky vote” critique — each person places dot stickers on the parts they find most promising. Then the Decider (a single empowered team member, usually the product leader) picks which solution to prototype.

On complex sprints, two competing concepts can be prototyped and tested head-to-head. Be aware: this significantly increases Thursday’s workload.

Once a concept is chosen, the team turns it into a storyboard — a comic-strip-style sequence of 10–15 frames showing exactly what the user will experience in the prototype. The storyboard acts as the prototype’s spec. It prevents scope creep and eliminates disagreements on Thursday before they start.

Thursday: Build a Realistic Prototype

The team builds a facade — something realistic enough that users will respond as if it were real, but no more finished than necessary. For a software product, this is typically a high-fidelity Figma prototype. For a physical product or service, it might be a printed brochure, a role-play script, or a Wizard-of-Oz simulation (where a human manually drives responses behind the scenes).

The guiding principle: prototype only what you need to test. There is no back-end, no error handling for edge cases, no exhaustive screen coverage. The prototype covers the storyboard frames and nothing else. Teams that over-polish Thursday’s prototype waste time that belongs to Friday’s analysis.

Friday: Test and Learn

Five users are interviewed one at a time while the team observes silently in a separate room (or via a shared screen session). The interviewer uses a semi-structured protocol: warm-up questions, open-ended exploration, then task-based scenarios with the prototype. The team takes notes on a shared grid — participants across the top, themes down the side — and looks for patterns across all five sessions before drawing any conclusions.

The Team and the Facilitator

A sprint needs a cross-functional team of five to seven people. GV’s recommended composition: a Decider (product leader), a designer, an engineer, a researcher or customer success representative, a marketing or business stakeholder, and one “troublemaker” — someone with a provocative perspective who will challenge comfortable assumptions.

The Decider is not the most vocal person in the room. They are the person with final authority. A sprint without a Decider devolves into endless consensus-seeking. Every exercise in the sprint feeds the Decider’s judgment — not to circumvent it.

The Facilitator (often called the sprint master) is a distinct role from team membership. The facilitator designs the schedule, runs each exercise, enforces timeboxes, and protects the process from derailment. Critically, the facilitator does not advocate for particular design decisions. This separation matters. A facilitator who pushes their own ideas corrupts the team dynamics the format was designed to create.

Modern Adaptations: Remote and Hybrid Sprints

The original sprint format assumed everyone was in one room for five days. Most teams today run sprints partially or fully remote. The toolset changes, but the underlying logic does not.

Remote sprints work best with a synchronous core and async preparation. Here are the key adaptations:

• Tooling: FigJam or Miro for collaborative mapping and voting; Figma for prototyping; Lookback or Maze for moderated remote testing.
• Timeboxing: Remote participants tire faster in video sessions. Break the five-day schedule into shorter blocks (three to four hours of facilitated time per day) and fill the gaps with async work.
• Pre-work: Send “How Might We” note templates and inspiration-gathering assignments before Monday’s session. This keeps meeting time focused on synthesis rather than initial input.
• Friday testing: Remote moderated testing with Zoom screen-share works well. The observation room becomes a shared Slack channel or a separate video call where the team watches without joining the test call.

The hardest part of a remote sprint is Wednesday’s decision. When sketches are shared digitally, the silent review and dot-vote work almost identically to in-person. However, the Decider’s final call benefits from a brief synchronous discussion. This surfaces any critical technical or legal constraints that did not appear in the sketches.

When to Run a Sprint — and When Not To

Design sprints are not a universal tool. They are well-suited to:

• High-stakes, ambiguous problems where the team disagrees about the solution direction
• New products or features entering an unexplored space
• Situations where a working prototype will unlock organizational alignment or secure stakeholder buy-in
• Teams that have been circling the same decision for weeks without reaching closure

They are poorly suited to:

• Well-understood execution problems where the solution is known and the work is implementation, not exploration
• Problems that require deep technical discovery before any user-facing concept can be formed
• Situations where Friday’s user feedback would not be trusted or acted on — this is typically a team or stakeholder culture problem that a sprint alone cannot solve
• Ongoing iterative product work where a continuous discovery cadence (weekly user sessions, regular ship-and-measure cycles) is more appropriate than a concentrated burst

A sprint creates urgency and alignment, but urgency is only valuable if the team is prepared to act on Friday’s findings. Running a sprint, watching users struggle with the concept, and then proceeding with the original plan anyway is a significant waste of participants’ time and team trust.

Sprint Results and What Comes Next

A sprint ends with one of three findings:

Sprint outcome	What it means	Recommended next step
Strong positive signal	Users understood the concept, completed tasks, expressed genuine interest	Proceed to full design; use sprint prototype as a fidelity anchor
Mixed or partial signal	Some elements worked; specific friction points identified	Iterate on problem areas; run a second sprint or a focused follow-on test
Clear negative signal	Users were confused, could not complete tasks, rejected the concept	Pivot the approach; return to problem definition before designing again

Sprint findings are qualitative and directional. They do not replace quantitative validation, accessibility review, technical feasibility assessment, or business-case analysis. A successful sprint tells you the concept is worth investing in — not that it is ready to ship.

The prototype built on Thursday is also not a delivery artifact. Hand-off to engineering should happen from a production-quality design file, not from a sprint prototype that was built to test one specific scenario under time pressure.

Metrics: Evaluating Sprint Effectiveness

Teams that run sprints regularly benefit from tracking sprint health metrics over time:

• Decision durability: Was the sprint’s Wednesday decision still in place three months later, or was it overturned? High overturn rates signal that the Decider lacked sufficient context or authority.
• Prototype fidelity to final product: How closely did the sprint concept match what shipped? Large divergence is not inherently bad — it may reflect legitimate learning — but consistent divergence with no documentation of why suggests sprint findings are not being incorporated.
• Time from sprint to validated design: If the gap between a sprint and a production-ready design consistently exceeds three months, the sprint’s urgency benefit is being lost in follow-on inertia.

Avoid measuring sprint success by participant satisfaction or whether the team “felt productive.” Those are process comfort metrics, not outcome indicators. A sprint that ends with a clear negative result and redirects a team away from an expensive wrong direction is an excellent sprint by any meaningful measure.