How to Run a Design Sprint in 5 Days: A Step-by-Step Guide
Some of the most important product decisions in modern tech history were made in a single week. Not by coincidence, but by design. The design sprint — a five-day structured process for solving critical product problems and testing solutions with real users — was developed at Google Ventures by Jake Knapp and his team, and introduced to the world in the 2016 book Sprint. Since then, it has been used by hundreds of companies worldwide, from pre-seed startups to global enterprises, to make faster, better-informed product decisions without months of debate or premature development.
The core promise of a design sprint is straightforward: compress months of work into five days. On Monday you map the problem. On Tuesday you sketch solutions. On Wednesday you decide on the best direction. On Thursday you build a realistic prototype. On Friday you test it with real users. By the end of the week, you have concrete evidence to guide your next move — whether that is building with confidence, pivoting dramatically, or shelving an idea before it consumes your engineering budget.
This guide walks you through every stage of the design sprint process, with practical guidance on what to do, what tools to use, and what pitfalls to avoid at each step.
What Is a Design Sprint?
A design sprint is a structured, time-boxed process that helps teams answer critical business questions through rapid design and user testing. It brings together cross-functional team members — typically a designer, a product manager, an engineer, a marketer, and a decision-maker — and runs them through a highly structured five-day agenda that eliminates endless meetings and premature building in favour of structured collaboration and rapid learning.
The original Google Ventures methodology, documented in Jake Knapp’s book and available in condensed form at thesprintbook.com, has spawned numerous adaptations — three-day sprints, remote sprints, mini-sprints — but the five-day structure remains the most comprehensive and most battle-tested format. This guide covers the classic five-day version, with notes on where and how to adapt it for your context.
When Should You Run a Design Sprint?
Not every product decision warrants a sprint. A design sprint is most valuable when you have a significant, high-stakes problem with multiple possible solution directions — where the cost of building the wrong thing would be significant, and where user input is likely to substantially change your thinking. Classic sprint triggers include: launching a new product or feature from scratch, redesigning a core user flow that is underperforming, entering a new market or user segment, or facing a strategic decision where your team is stuck in irresolvable debate.
A design sprint is less appropriate for incremental improvements with an obvious solution, problems that don’t require user validation, or situations where no decision-maker can commit five consecutive days to the process. The last point is critical: without a genuine decision-maker in the room with the authority to commit to a direction, the sprint’s output will not lead to action, and the investment is wasted.
Before You Begin: Setting Up for Sprint Success
The quality of a design sprint is determined in large part by the decisions made before it begins. Rushing the setup is the single most common cause of sprint failure.
Choose the Right Challenge
Write a clear sprint question — a single sentence that captures the core challenge the sprint will address. The best sprint questions are specific, user-centred, and framed around a goal rather than a solution. Not 'How do we redesign the dashboard?' but 'How might we help first-time users understand the value of the dashboard within their first session?' The question becomes the north star for every decision made during the five days.
Assemble the Right Team
The ideal sprint team has five to seven people with diverse expertise relevant to the problem: a designer, a product manager, an engineer, a customer-facing person (sales, support, or customer success), and a decision-maker with the authority to commit to the sprint’s outcome. The Decider — as the methodology calls them — does not need to be present every minute but must be available for key decision moments, particularly on Day 2 and Day 3.
Recruit User Testers Now
This is the step most teams leave too late. You need five real users scheduled for individual 30 to 60 minute testing sessions on Friday. Recruit them before the sprint begins. Identify your target user profile, find participants through your existing user base, a research recruitment platform like Respondent.io, or relevant communities, and confirm all five sessions before Monday morning. Without confirmed testers, Day 5 cannot happen, and a sprint without Day 5 is just an expensive workshop.
Day 1: Understand — Map the Problem
Day 1 is about building a shared understanding of the problem, the user, and the landscape. The sprint team starts the week with different mental models of what the problem is and what users need. Day 1’s goal is to align everyone on a single, evidence-based view.
Expert Interviews (Morning)
The morning is spent in structured interviews with internal experts — people who know a specific aspect of the problem deeply. The customer support lead who hears from confused users daily. The sales rep who knows why prospects choose competitors. The engineer who understands the technical constraints. Each interview is time-boxed (typically 15 to 30 minutes) and the team takes notes using the How Might We format: capturing every insight as a question that begins with ‘How might we…’
Map the User Journey (Afternoon)
In the afternoon, the team creates a simple map of the user journey — the steps a user takes from their initial awareness of a problem to achieving their goal using your product. The map is deliberately simple: five to fifteen steps, written as short verb-noun phrases, arranged left to right. Once the map exists, the team votes on which part of the journey to focus the sprint on. This focus decision — choosing where on the map to intervene — is one of the sprint’s most consequential choices.
Set the Long-Term Goal and Sprint Questions
End Day 1 by agreeing on the long-term goal — the outcome you are ultimately working toward — and a set of sprint questions: the assumptions and risks that could prevent you from reaching that goal. These questions guide what the prototype will test on Friday. They are the hypotheses the sprint is designed to validate or invalidate.
Day 2: Diverge — Sketch and Explore
Day 2 is about generating ideas — lots of them — and then converging on the most promising directions through structured sketching. The sprint methodology deliberately sequences individual work before group discussion, because groups brainstorming together are significantly less productive than individuals brainstorming independently and then sharing results.
Lightning Demos (Morning)
Each team member spends the morning researching and presenting ‘lightning demos’ — quick, three-minute showcases of existing products, features, or approaches that contain ideas worth stealing. These do not have to be direct competitors: a checkout flow from an unrelated industry, a data visualisation from a news organisation, or an onboarding pattern from a consumer app can all provide inspiration relevant to your problem. The goal is to build a shared reference library of ideas before anyone starts sketching.
The Four-Step Sketch (Afternoon)
The afternoon follows a structured four-step sketching process that moves from messy exploration to a detailed, annotated solution sketch.
Notes (20 minutes): each person walks around the room reviewing the sprint materials and taking personal notes.
Ideas (20 minutes): transform notes into rough sketches and ideas without worrying about quality.
Crazy 8s (8 minutes): fold a sheet of paper into 8 sections and sketch 8 distinct variations of one idea in 8 minutes — this forces rapid exploration beyond the obvious first answer.
Solution Sketch (30 to 60 minutes): create one detailed, three-panel solution sketch that tells the story of a user interacting with the proposed solution from start to finish.
All sketches are done on paper and kept anonymous until Day 3. This is a deliberate design of the methodology: anonymity reduces groupthink and ensures ideas are evaluated on their merits rather than the seniority of the person who drew them.
Day 3: Decide — Select the Best Direction
Day 3 is arguably the most valuable day of the sprint because it is where the team’s diverse perspectives are synthesised into a single, committed direction — without the politics, hierarchy, and endless debate that usually accompany strategic decisions.
The Art Museum and Heat Map Vote (Morning)
Solution sketches are posted on the wall in gallery format — still anonymous. Each team member silently reviews all the sketches and places dot stickers on the parts they find most interesting, promising, or relevant to the sprint questions. This creates a visual heat map of which ideas resonate across the team, and it happens without discussion to prevent anchoring effects and social conformity.
Rumble vs Storyboard
After the heat map vote and a structured critique session, the Decider makes the final call on which solution — or which combination of solutions — will be prototyped. If two strong, incompatible directions emerge, the team may choose to run a ‘rumble’: prototyping both concepts and testing them head-to-head with users on Friday. The afternoon is spent creating a storyboard — a step-by-step panel-by-panel comic of the prototype, typically 8 to 15 panels, that will guide Thursday’s prototyping work.
Day 4: Prototype — Build Just Enough
Day 4 is the most intense day of the sprint. The team’s goal is to build a realistic, believable prototype in a single day — not a finished product, but something realistic enough that users will respond to it as if it were real. The prototype needs to answer the sprint questions from Day 1, not satisfy every use case or edge condition.
The Goldilocks Quality Rule
Sprint prototypes should be neither too rough nor too polished. Too rough (hand-drawn sketches photographed on a phone) and users spend their attention compensating for the prototype’s crudeness rather than responding to the concept. Too polished (fully coded, pixel-perfect) and users are reluctant to give critical feedback and your team has wasted time on execution quality that provides no additional learning. The Goldilocks zone is a realistic-looking, clickable prototype built in a tool like Figma, Keynote, or Marvel — appearing finished but built in hours, not days.
Roles on Prototype Day
Makers (2 to 3 people) — build the individual components of the prototype based on the storyboard; typically the designer and one or two other team members who can work in the prototyping tool
Stitcher (1 person) — assembles the components into a coherent, navigable prototype flow and tests it for basic functionality
Writer (1 person) — creates all the realistic copy that the prototype needs; placeholder text signals a prototype to users and breaks the illusion of reality
Interviewer (1 person) — writes the interview script for Friday’s user testing sessions; this person will run all five sessions and should not be making the prototype
Day 5: Test — Learn from Real Users
Friday is the day the sprint earns its return. Five individual user testing sessions, each 30 to 60 minutes long, are run back to back. One person — the interviewer — runs each session with the participant, guided by the interview script. The rest of the team watches via a live video feed or screen share from a separate room, taking notes on their observations.
The Five-Act Interview
Welcome — put the participant at ease, explain the session format, and emphasise that you are testing the product not them; mistakes are the prototype’s fault, not theirs
Background questions — warm up with open-ended questions about the participant’s relevant habits, behaviours, and context to establish their mental model before they see anything
Introduce the prototype — frame it as an early concept that other people built and that you want their honest reaction to; this framing reduces politeness bias
Tasks — give the participant specific tasks to complete using the prototype; observe without assisting, and prompt them to think aloud throughout
Debrief — close with open questions about overall impressions, specific moments of confusion or delight, and what they would expect the product to do next
Pattern Finding at the End of Day 5
After all five sessions, the whole team gathers to review their notes and identify patterns. Look for observations that appeared in three or more of the five sessions — these are the reliable signals. Single-session observations are noise; repeated observations are data. Organise findings into three categories: what worked well, what was confusing, and what was missing or unexpected. These three lists form the sprint’s output and directly inform the next decision.
What to Do With Sprint Results
Design sprint results typically fall into one of three outcomes:
validate (the concept worked well and users responded positively — build it with confidence),
iterate (the concept showed promise but specific elements failed — refine those elements and test again),
or invalidate (the core concept did not land with users — the assumptions were wrong and a fundamentally different approach is needed).
All three are valuable outcomes. Invalidating a bad idea in five days, before it consumes months of engineering time, may be the sprint’s most important contribution to a product team’s velocity.
Adapting the Sprint for Your Context
The five-day sprint is a framework, not a prescription. Many teams run successful adapted versions. A three-day sprint compresses the timeline by combining Day 2 and Day 3 and running a lighter prototype. A remote sprint replaces the physical room with FigJam or Miro for collaborative mapping and digital dot voting, with video calls for structured discussions. A mini-sprint — sometimes called a design sprint lite — focuses on a single screen or flow rather than an end-to-end journey, and can be completed in as little as two days.
For running remote sprints effectively, the Remote Design Sprint guide from the Sprint Book team is the most comprehensive resource available. For digital collaboration during sprints, Miro’s design sprint template and Figma’s design sprint kit are both well-structured starting points.
The design sprint is not a shortcut. It is a discipline. It works not because it is fast, but because it is structured — every decision is made with intention, every idea is tested with evidence, and every day builds directly on the one before.
The Design Sprint Facilitator: Do You Need One?
The Facilitator runs the sprint, manages time, enforces the structure, and ensures the process produces a decision rather than a conversation. In an ideal sprint, the Facilitator is someone who has run multiple sprints before and is not personally invested in any particular solution outcome. For a team’s first sprint, bringing in an experienced external facilitator is an investment that typically pays for itself many times over in the quality of the output and the speed of the process.
At Afrodity Designs, we facilitate design sprints for product teams at every stage — from early-stage startups validating their first core feature to established businesses tackling a strategic redesign challenge. If you have a problem worth solving in five days, we would love to help you structure the sprint and facilitate the process from challenge definition to validated prototype.
Final Thoughts: Five Days That Change How You Build
The design sprint does something that most product processes do not: it forces a team to stop talking about what might work and start learning what actually works — in the fastest, most resource-efficient way possible. The five days are intense, structured, and deliberately uncomfortable in places. But the output — a validated prototype and a room full of people who share a concrete, evidence-backed understanding of their users — is something no amount of meetings or decks can replicate.
If you have never run a design sprint before, start small: pick one significant, unresolved product question, gather the right people, and follow the process. The sprint framework is forgiving of first-time imperfection. What it is not forgiving of is skipping Day 5 — because the test is the whole point.
