How to Run a Design Sprint

A design sprint is a structured five-day process for solving a specific product challenge — from problem definition to tested prototype. It compresses months of iteration into a single week by forcing decisions and skipping the endless committee discussions that slow most product work.

The methodology was developed at Google Ventures (GV). The book "Sprint" by Jake Knapp is the primary reference. What follows is a practical implementation guide.

When to run a sprint

A sprint makes sense when:

• You have a significant product decision with real uncertainty
• You need stakeholder alignment on direction
• You want to validate an idea before committing to full development

It doesn't make sense for small features, incremental improvements, or when the solution is already obvious. A sprint is expensive — it takes five people out of their regular work for a week.

Participants

You need 5–7 people. Larger groups become unmanageable.

• Facilitator (1): Runs the sessions, enforces time boxes, keeps energy up. Usually the design lead or a UX researcher.
• Decider (1): The person with authority to make the final call when the group can't agree. Product manager, founder, or business owner.
• Designer (1–2): Responsible for the Thursday prototype.
• Engineer (1): For feasibility input and the build perspective.
• Domain expert (1–2): Customer success, sales, or a subject matter expert who knows the problem deeply.

Everyone participates fully. Part-time sprint participants don't work.

Day-by-day breakdown

Monday: Map

Goal: Align on the problem and choose a focus.

Start with a long-term goal: "In two years, what does success look like?" Work backward to identify the biggest risk or uncertainty.

Map the user journey: a simplified flow showing how users currently navigate the problem space. Each participant draws their version, then the group synthesizes.

The "How Might We" exercise generates opportunity questions from problems. Every time someone mentions a problem, someone writes a "HMW..." note on a sticky. Sort them at the end and vote on the most promising.

Close Monday by picking a target moment — the single step in the user journey where you'll focus your sprint effort.

Tool: Miro or FigJam for the journey map and sticky note exercises.

Tuesday: Sketch

Goal: Generate solution concepts, individually.

Tuesday is deliberately individual. No group brainstorming — research shows groups brainstorm worse than individuals working alone, then sharing.

Run a "Lightning Demos" session first: each participant shares examples of relevant products or features they find inspiring (not necessarily from your industry). 3 minutes each.

Then individual sketching: four rounds of increasing fidelity over the course of the day, ending in a detailed "Solution Sketch" — a three-panel storyboard showing the user's experience through the key moment.

Solution Sketches are paper or digital, detailed enough that someone else can understand the concept without explanation.

Wednesday: Decide

Goal: Choose one solution to prototype.

Wednesday is decisions, not more exploration. The team reviews all solution sketches silently (the "Museum Walk"), adds dot vote stickers to interesting elements, then the Decider makes the call.

The key ceremony: the Rumble or All-in-One decision. If the top concepts are similar enough, combine them. If they represent genuinely different bets, choose one.

End Wednesday with a storyboard: a 12–15 panel comic-strip of the prototype you'll build on Thursday. This is the blueprint. Every detail should be decided here so Thursday is pure execution.

Tool: Miro or FigJam for voting and the storyboard template.

Thursday: Prototype

Goal: Build a realistic prototype in one day.

Realistic doesn't mean functional. It means realistic enough that users during Friday's test can give genuine reactions. A Figma prototype with 5–8 screens is usually sufficient.

Divide labor: One person handles Figma (building screens), one handles assets, one writes the copy, one prepares the test script, and the facilitator coordinates.

The prototype should cover the user journey from the "opening scene" (how the user arrives) through the key moment and to the ending. Fake data is fine. Placeholder images are fine. Broken flows are not — the prototype needs to be clickable end-to-end.

Try Figma for Prototyping

Friday: Test

Goal: Get reactions from 5 real users.

Five user interviews, 1 hour each. The facilitator runs the session; the rest of the sprint team observes on a video feed and takes notes.

Use a structured interview format: background questions → introduce the prototype → task scenario → follow-up questions. Don't explain the prototype. Watch where users get confused.

After five sessions, the sprint team synthesizes notes. Look for patterns: what worked, what confused people, what the prototype didn't answer. These findings guide the next steps — whether that's building, iterating, or pivoting.

Remote sprint adjustments

In-person sprints are easier to facilitate, but remote sprints work. Adjustments:

• Use Miro or FigJam consistently throughout — don't mix tools mid-sprint
• Add 30-minute breaks between sessions (screen fatigue is real over five days)
• Use video for all sessions — cameras on, not optional
• Replace paper sketching with Figma sketch frames or a digital whiteboard
• Run user interviews via Zoom with screen sharing for the prototype

What happens after the sprint

A sprint doesn't end with a shipping decision. It ends with validated learning.

If the prototype tested well, you've de-risked the concept enough to commit to building. Take the sprint output to your product planning process and spec the real implementation.

If it tested poorly, you've saved yourself the cost of building the wrong thing. Review what you learned and decide whether to sprint again on a different approach, or change direction entirely.

Either outcome is a success.