A design sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with real users. Developed at Google Ventures (GV) by Jake Knapp, the design sprint compresses months of debate, design, and development into a single week that produces a tested prototype and actionable learning. It is one of the most efficient methods for reducing uncertainty before committing significant resources to building a product or feature.

The Design Sprint: From Problem to Tested Prototype in Five Days

When to Run a Design Sprint

Design sprints are most valuable when:

A team is debating multiple directions and needs a structured way to decide
The stakes are high enough to justify a week of focused work
A product or feature concept needs validation before development begins
A team is stuck and needs a forcing function to move forward

Design sprints are not appropriate for incremental improvements to existing features, bug fixes, or well-understood problems with obvious solutions. They are a tool for exploration and validation under uncertainty.

The Five Days

Monday: Map and Choose a Target

The team maps the problem space by creating a simple diagram of the customer journey from start to end goal. Stakeholders and subject matter experts share their knowledge, constraints, and existing research in structured “How Might We” sessions.

By the end of Monday, the team selects a specific part of the map to focus on — a target customer and a target moment in their journey. This focus is critical. A design sprint that tries to solve the entire problem space will solve nothing.

Key activities:

Long-term goal setting (what does success look like in two years?)
Sprint questions (what are the riskiest assumptions?)
Customer journey map
Expert interviews (15-30 minutes each)
Target selection

Tuesday: Sketch Solutions

Each team member works individually to sketch solutions. This is not group brainstorming — research shows that individuals working alone generate more and better ideas than groups brainstorming together.

The morning starts with inspiration: reviewing existing products, competitor approaches, and analogous solutions from other industries. The afternoon is dedicated to solution sketching, following a structured process:

Notes: Review the map and sprint questions (20 minutes)
Ideas: Rough sketches exploring multiple approaches (20 minutes)
Crazy 8s: Fold paper into eight sections and sketch eight variations in eight minutes
Solution sketch: A detailed, three-panel storyboard of the best idea (60 minutes)

Solution sketches are anonymous — the team evaluates ideas on merit, not on who drew them.

Wednesday: Decide

The team reviews all solution sketches using a structured silent critique. Team members vote on the strongest ideas using dot stickers, then the Decider (usually a product lead or founder) makes the final call on which solution to prototype.

The afternoon is spent creating a storyboard — a step-by-step plan for the prototype that the team will build on Thursday. The storyboard serves as the blueprint: every screen, interaction, and user step is mapped.

Decision-making approach:

Silent review and voting prevents groupthink
The Decider has final authority, preventing endless committee debate
Conflicting ideas can sometimes be combined or tested as separate variants

Thursday: Prototype

The team builds a realistic-looking prototype in a single day. The prototype is not functional code — it is a facade that looks real enough to generate honest user reactions. Common prototyping tools include Figma, Keynote, or even paper prototypes depending on the product type.

Key principles:

The prototype must test the specific hypotheses from Monday
It should look realistic enough that users engage naturally
It does not need to be beautiful — it needs to be testable
Assign roles: Maker(s) build the prototype, Writer creates content, Asset Collector gathers images and copy, Interviewer prepares the test script

Friday: Test

Five target users test the prototype in one-on-one moderated sessions, each lasting about 60 minutes. The rest of the team watches via live stream in a separate room, taking notes on patterns.

Five users are sufficient to identify major usability issues and validate or invalidate the core concept. By the third or fourth interview, patterns emerge clearly.

Test structure:

Warm-up questions about the user’s background and current behavior (5 minutes)
Introduce the prototype without explaining what it does (2 minutes)
Give the user tasks and observe how they interact (40 minutes)
Debrief questions about their experience (10 minutes)

After the Sprint

The sprint produces one of three outcomes:

Validated concept. Users understood, liked, and would use the solution. Move into MVP development with confidence.
Partially validated. Some elements worked, others failed. Iterate on the prototype and test again, or run a follow-up sprint.
Invalidated concept. Users did not understand or did not want the solution. This is a valuable outcome — the team learned in five days what would have taken months to discover through development.

All three outcomes save time and money. Even an invalidated concept is a win because the team avoided building something nobody wants.

Running a Design Sprint Remotely

Remote design sprints use video conferencing and collaborative tools:

Miro or FigJam for mapping, sketching, and voting
Figma for prototyping
Zoom or Google Meet for moderated testing
A shared timer to keep the schedule tight

Remote sprints require stricter facilitation because it is easier for participants to disengage. Shorter daily sessions (4-5 hours instead of 6-8) with breaks help maintain energy.

Team Composition

The ideal design sprint team has 5-7 people:

Role	Why They Are Needed
Decider	Makes final calls, usually a product or business leader
Product manager	Brings user and market knowledge
Designer	Creates the prototype
Engineer	Provides technical feasibility input
Customer-facing role	Brings real user insight (support, sales)
Facilitator	Runs the process, keeps time, manages energy

The Facilitator role is critical and should not be combined with another role. A good facilitator keeps the sprint on schedule, manages group dynamics, and ensures the process is followed. Without a facilitator, sprints devolve into unstructured workshops.

Adapting Sprint Length

The classic five-day sprint is not always practical. Shorter variations exist:

Four-day sprint: Combine Monday and Tuesday, sprint from Tuesday to Friday
Three-day sprint: Map and decide on Day 1, prototype on Day 2, test on Day 3
Mini-sprint (one day): Sketch, prototype, and test a single interaction in eight hours

Shorter sprints sacrifice depth for speed. Use them for lower-stakes questions or when the team cannot dedicate a full week.