What Is a Design Sprint? The Five-Day Process Explained

The phrase "design sprint" gets thrown around a lot in product and UX circles. Sometimes it means a focused week of structured work. Sometimes it just means "we moved quickly." This post is about the real thing: the five-day sprint process developed at Google Ventures, what happens in each phase, when it's worth using, and when it isn't.

If you're studying UX or moving into the field, understanding design sprints is genuinely useful. They come up in job interviews, they appear in team culture at many product companies, and they illustrate some of the best ideas in applied UX work.

Where Design Sprints Come From

The design sprint was created by Jake Knapp while he was working at Google, and later codified during his time at Google Ventures (GV), the investment arm of Alphabet. His 2016 book Sprint, co-written with John Zeratsky and Braden Kowitz, made the method widely accessible.

GV used the sprint to help portfolio companies answer high-stakes questions quickly - without building a full product first. The core proposition was straightforward: compress months of back-and-forth into five focused days, end with a realistic prototype, and test it with real users before spending serious money.

The method drew from design thinking, agile, and behavioural science. But unlike design thinking, which is a broad mindset and process framework, a design sprint is a specific, timed structure with named activities for each day. It's closer to a recipe than a philosophy.

For more on how design thinking relates to this work, see our post on design thinking in UX.

The Five Phases

A classic GV design sprint runs Monday through Friday. Each day has a clear purpose. Here is what happens and why it matters.

Phase 1: Understand and Map

Day one is about aligning the team on the problem.

Before anyone sketches anything, the sprint opens with a structured effort to surface what everyone knows - and doesn't know. The team talks to internal experts, maps the user journey end to end, and defines the long-term goal.

A key tool here is the "How Might We" format: turning problems into open questions. "Users abandon checkout" becomes "How might we make checkout feel less risky?" This small linguistic shift keeps the focus on possibility rather than blame.

By the end of Monday, the team picks one specific target moment on the map - the part of the journey they'll focus on for the rest of the week.

Example: A team at an online estate agent runs a sprint on their property listing experience. On day one, they map the journey from search to booking a viewing. They identify that the moment users read the property description is where most of them leave. That moment becomes the sprint target.

Phase 2: Sketch

Day two is individual, divergent idea generation.

Rather than a group brainstorm - which research consistently shows is less effective than individual thinking - each person on the team works alone to sketch solution ideas. The format is structured: first you review what competitors and analogous products do, then you produce detailed sketches of your proposed solution.

The output isn't a polished wireframe. It's a "solution sketch": a three-panel storyboard showing how a user would experience the proposed solution. Crucially, each sketch is anonymous at this stage. That removes the pull toward group consensus and the tendency to defer to the most senior person in the room.

Example: The estate agent team each sketch their own version of a redesigned property description. One person proposes a "key facts" summary at the top. Another suggests a "questions answered" section drawn from common buyer queries. A third focuses on social proof - showing how many people have viewed and saved the property.

Phase 3: Decide

Day three is about making a choice and planning what to build.

All the sketches from Tuesday go up on the wall. The team reviews them systematically - using dot voting, structured critique, and a final decision by the sprint's "Decider" (usually the project owner or a senior stakeholder). The goal is to pick the strongest idea, or to identify compatible ideas that can be combined.

By the end of Wednesday, the team has a storyboard: a step-by-step plan of the prototype they'll build the next day. This isn't optional. You need a detailed storyboard before you build anything, or Thursday becomes chaos.

The Decider role is important and deliberate. Design sprints resist consensus decision-making. Someone has to own the call. That person is named in advance.

Example: The estate agent team vote on the sketches. The "key facts" summary and the "questions answered" section both get high scores. The Decider chooses to combine them into a new property page layout. The storyboard maps out exactly what a user will see from search result through to booking.

Phase 4: Prototype

Day four is focused execution.

The team builds a realistic-looking prototype - not a fully functional product, but something good enough to put in front of a real user and get genuine reactions. The standard in GV sprints is to use tools like Figma, Keynote, or even recorded screen walkthroughs.

The key principle is "fake it until you test it." You aren't building for engineers. You're building for your test participants. A clickable Figma prototype that looks like a real website is sufficient.

Thursday is intense. It works because the storyboard is already done - you're executing a plan, not making decisions.

Example: The estate agent team build a Figma prototype of the new property listing page. It includes the key facts summary, the questions section, and real photos from an existing listing. It isn't connected to their database. It doesn't need to be. It needs to look right and feel real to someone clicking through it on a laptop.

Phase 5: Test

Day five is where you find out if the idea actually works.

On Friday, the team watches five real users interact with the prototype in one-to-one usability sessions (for a full guide on how to structure and run these, see our usability testing guide). The interviews follow a structured format: a short warm-up, then task-based exploration, then debrief questions.

Five users is a deliberate choice. Research by Jakob Nielsen showed that five qualitative sessions surface the majority of significant usability issues. You don't need a large sample to spot patterns - you need the right participants and careful observation.

The team watches the sessions together (often via a shared video link or observation room) and takes structured notes. By end of day, they have a clear picture: does the idea solve the problem, partially solve it, or miss the mark?

Example: Three of the five estate agent users immediately engage with the key facts summary. Two read the "questions answered" section in full before clicking through to book a viewing. One user is confused by the layout on mobile. The team has a clear steer: the concept works; mobile layout needs rework.

When a Sprint Is the Right Tool

Design sprints work best in specific conditions.

• The team is aligned that there's a real problem but genuinely uncertain about the solution.
• The problem is concrete enough to test in a five-day window - a specific user journey, a key decision point, a product feature.
• Real users are accessible for Friday's testing.
• A decision-maker (the Decider) can commit five days and make a call.
• The stakes justify the investment - a significant product decision, a new market entry, a redesign of a high-traffic flow.

Sprints are particularly valuable when a team has been stuck in prolonged discussion without resolution. The structure forces a decision. That alone is often worth the week.

When a Sprint Is Not the Right Tool

Sprints aren't a cure-all.

Exploratory research. If you don't yet understand your users' lives, needs, or mental models, a sprint is premature. You need discovery work first - interviews, field research, diary studies. A sprint assumes you have enough understanding to sketch solutions.

Complex, multi-faceted systems. A sprint tests one specific slice of a problem. If the challenge is structural - a broken information architecture, a fragmented service, a multi-channel experience - a single sprint won't cover it.

Purely technical problems. Sprints are for human-centred design questions. If the blocker is a legacy API or a data pipeline, a design sprint isn't the answer.

Ongoing improvement work. Sprints are high-effort and time-boxed. Continuous iteration on a live product usually calls for lighter methods: A/B testing, analytics review, short rounds of usability testing.

The Benefits

When the conditions are right, design sprints offer real advantages.

Speed. Five days from question to user-tested insight is genuinely fast. The alternative is often months of meetings, misaligned assumptions, and a product launch that reveals problems that could have been caught earlier.

Alignment. Bringing a cross-functional team through the same process - map, sketch, decide, build, test - creates shared understanding. Everyone has seen the same user responses. Disagreements become easier to resolve.

Reduced risk. A prototype test on day five costs a fraction of building the full product. If the idea doesn't land, you have lost a week - not six months of engineering time.

User evidence over opinion. Sprints end with data. Not a survey, not stakeholder intuition - real humans using something that looks like your product.

The Limitations

Honest assessment matters here.

Five users on Friday doesn't constitute definitive research. It surfaces patterns and identifies obvious problems - which is valuable - but it isn't a statistically robust study. Decisions based on sprint findings should still be validated over time.

Sprints also require genuine commitment. If the team can't protect five full days, or if the Decider isn't present for key moments, the process degrades. A "sprint" in name only - where people dip in and out, skip Thursday, and present to stakeholders instead of testing with users - isn't a sprint.

And sprints can create a false sense of resolution. The test on day five shows whether your solution idea is broadly on track. It doesn't mean the work is done.

Compressed and Remote Sprints

The classic five-day format has spawned many variations.

Three-day and four-day sprints compress the original by combining some phases or reducing the number of sketches and decision rounds. They work when the team has strong existing research and a well-defined problem.

Remote sprints became standard during and after the pandemic. Tools like Miro, FigJam, and Maze make remote sketching, voting, and even prototype testing viable. Remote sprints require more structure and discipline - it's harder to sustain energy over video calls - but they're now a normal part of how product teams work.

Some organisations run "mini sprints" of two or three days focused only on a specific phase - for example, a decision day and a prototype-and-test day when the problem is already well understood.

How Design Sprints Relate to UX

A design sprint isn't a substitute for ongoing UX practice. It's a focused intervention for a specific kind of question.

In a mature product team, sprints typically sit alongside continuous discovery work: user interviews, usability testing, analytics, and design thinking as a broader orientation. Sprints are the power tool you reach for when speed and alignment are both critical.

If you want to understand where sprints fit in the wider picture, our introduction to what UX design is covers the full scope of the discipline - research, design, prototyping, and testing - and how these methods connect. For a step-by-step view of how UX work is typically structured outside a sprint context, see our guide to the UX design process.

Understanding usability is also worth your time before you run your first sprint. Testing a prototype without a clear framework for evaluating what "works" often leads to vague feedback that's hard to act on.

Where to Go From Here

If you want to run a design sprint, Jake Knapp's book Sprint is the primary source. The full facilitation guide is also available free at the GV website. The method is well-documented and genuinely learnable.

If you want to build the broader UX skills that make sprints more effective - research methods, facilitation, prototyping, usability testing - that's what we teach at UX Academy (myuxacademy.com).

Our Beginner UX (AI) Design course covers the core process end to end, including hands-on prototyping and research, and is taught live by our lead instructor, Natalia Veretenyk, and her team. If you want to see what the curriculum looks like before committing, book a free 15-minute call with an advisor.

Design sprints are a powerful method. Used in the right context, with the right preparation, they consistently produce insights that months of internal debate can't. That's why they have become a fixture in product and UX teams - and why understanding them matters if you're serious about a career in the field.