Design Sprint: The Five-Day Method, Day by Day

A design sprint is a five-day process for answering a critical business question through design, prototyping and testing an idea with real customers. It was developed at GV, the venture arm of Alphabet, and published by Jake Knapp in the book Sprint. The format is fixed on purpose: one problem, one week, one prototype, five interviews on Friday. This guide covers what happens each day, what has to be true before Monday, what a sprint does not solve, and where a monthly design subscription fits next to it.

What a design sprint is

The sprint compresses the debate that normally takes months into one week, and ends with evidence instead of an opinion. GV describes it as a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers. Wikipedia frames it as a time-constrained, five-phase process aimed at reducing the risk of bringing a new product or feature to market.

The point is not speed for its own sake. The point is that you find out whether people understand and want the thing before an engineering team spends a quarter building it. A prototype that fails on Friday is the cheapest failure available.

• Time-boxed: five consecutive days, full-time, with the same people in the room.
• Single-question: one challenge, chosen before Monday. A sprint that tries to answer three questions answers none.
• Decider-led: one person with authority breaks ties. Consensus is explicitly not the goal.
• Evidence-producing: the output is five customer interviews and what they revealed, not a deck.

The five days, one at a time

The daily structure below follows the schedule GV publishes, which is also the one taught in the Sprint book and mirrored by Atlassian and other write-ups.

Monday: map the problem and pick a target

The team builds a shared map of the customer journey, hears from experts inside the company, and the decider picks one moment on that map to attack. Most of Monday is spent discovering that the team did not agree on the problem, which is the day doing its job.

Tuesday: sketch competing solutions

Everyone sketches, individually, on paper. No group brainstorming, no whiteboard consensus. The output is several detailed and genuinely different solutions rather than one averaged idea that nobody believes in.

Wednesday: decide

The sketches go up on a wall, get critiqued without their authors defending them, and get voted on. The decider chooses what gets prototyped, and the team writes the storyboard that Thursday will build. This is the day that most often runs long.

Thursday: build the prototype

A realistic facade, not a product. Enough screens, in enough fidelity, that a customer forgets they are looking at a mockup. Nothing is coded. The discipline is deciding what can stay fake, which is a skill and not a shortcut.

Friday: test with five customers

Five one-on-one interviews, the rest of the team watching from another room and taking notes. By the end of the afternoon the patterns are usually obvious, and the week has produced a decision that survives the next meeting.

What has to be true before Monday

Sprints fail during preparation more often than during the week. The logistics decide the outcome, and the recruiting is the part teams systematically underestimate.

• The five testers are booked before Monday: recruiting customers who match your target and will show up on a Friday afternoon takes a week of lead time by itself.
• The decider is in the room all five days: a decider who dials in for an hour on Wednesday turns the sprint into a workshop with no authority behind it.
• The team is cross-functional and small: design, product, engineering, plus someone who talks to customers daily. Seven people is a crowd.
• The calendar is genuinely cleared: part-time participation breaks the format, because Tuesday depends on everyone having heard Monday.
• The question is worth a week: sprints are expensive in senior time. Spending one on a question you could answer with an afternoon of analytics is the most common waste.

GV publishes free checklists, videos and per-day guides, and Character maintains a step-by-step version of the same material. There is no reason to pay for the method itself.

What a sprint does not solve

The format is precise about what it produces, and vague claims around it are what give it a bad reputation on the second attempt.

• It does not produce a shippable product. Thursday builds a facade, and the build effort starts after the sprint, not during it.
• It does not replace continuous research. Five interviews on one prototype is a strong signal about one flow, not a picture of your user base.
• It does not fix an organizational problem. If the decider cannot decide on Wednesday, the sprint surfaces that and nothing more.
• It does not answer a question that depends on data you do not have. A pricing question with no willingness-to-pay evidence stays unanswered.

When the question is really about an existing product that already has traffic, a UX audit of the live site usually finds more in two days than a sprint finds in five, because the evidence already exists in the analytics.

Design sprint, design thinking and an agile sprint are three things

The words overlap and the practices do not. Mixing them up is the fastest way to end up with a week that satisfies nobody.

• Design thinking is a mindset and a family of methods, with no fixed duration. A design sprint is one packaged, time-boxed application of it.
• An agile sprint is a development cycle, usually one to four weeks, whose output is shipped code. A design sprint produces a prototype and interview findings, and nothing gets shipped.
• A design sprint is a single week with a fixed agenda, a named decider and customer testing on the last day. Remove any of those three and it becomes a workshop.

Teams that run both keep them separate on the calendar. The sprint answers what to build, the agile cycles build it, and the interface work in between is continuous rather than event-driven.

Templates, tools and running it remotely

The material is public and the tooling question is smaller than it looks. What matters is that everyone sees the same artifacts at the same time.

• The method and its materials: the Design Sprint Kit published by Google covers the phases and the exercises, at no cost.
• The checklists: GV free per-day guides and videos and the step-by-step version maintained by Character.
• The remote board: a collaborative whiteboard such as Miro, which publishes its own sprint guide and templates.
• The prototype: Figma, linked screens only. The temptation to build something real on Thursday is the main reason Thursdays run late.

Remote sprints work, with one adjustment that is not optional: the day gets split into shorter blocks, because five straight hours on a video call produces worse sketches than four hours in a room. The Friday interviews are the easiest part to run remotely and the hardest part to skip.

What a sprint costs, and who runs it

The visible cost is the facilitator, and almost no facilitator publishes a rate. The invisible cost is larger and easier to calculate: five days of four to six senior people, plus the recruiting and incentives for the customers you interview on Friday. Price that internal week first, because it is usually the bigger half and it is the number that decides whether the sprint is worth running.

The method itself is free and well documented. Google publishes a Design Sprint Kit with the methodology and the materials. A good facilitator is not selling you the method, they are selling neutrality and the discipline to end Wednesday on time.

Sprint or subscription: two different purchases

A design sprint is a one-off engagement with a fixed week and a fixed question. A monthly design subscription, which is what Design Elite sells, is the opposite shape: a dedicated team working continuously on whatever the queue holds. Confusing the two is how companies end up disappointed in both.

Here is the honest split, including the parts that do not favor us.

• A sprint is the right purchase when you have one high-stakes question, a week you can actually clear, and customers you can recruit. Hire a facilitator who does this full time, ideally with a research background.
• A subscription is the right purchase when the design work never stops: new screens every week, a design system that keeps growing, iterations on live flows, landing pages around each launch.
• We cannot run the Friday of a real sprint: moderated user research, recruiting and interviewing participants, is not one of our services. We work from research someone else ran.
• We cannot build what Thursday validates: development and integration are outside what we do. The prototype and the specs are ours, the code is yours or your dev partner.
• What we do fit: the design work a sprint creates on the other side. A validated concept becomes flows, wireframes, a real interface and a component system, which is exactly the continuous phase a sprint hands off to.

Our pricing is published rather than quoted: Prestige at 949.90 EUR excl. tax per month, Elite at 1,399.90 EUR and Commando at 2,099.90 EUR, all with no commitment, and Prestige at 759.90 EUR excl. tax per month on a 12 month commitment. We bill in euros from our Paris studio and work in English, with an overlap that covers the morning of the US business day on Eastern time. See the plans in detail or the UX/UI design service if the continuous shape is what you need.

If you are choosing between running a sprint and starting design work directly, the test is whether you can name the question the sprint would answer in one sentence. If you can, the week is probably worth it. If the sentence keeps turning into three sentences, what you have is a backlog, and a backlog is served by a process rather than an event. Our UX design methodology and the UX/UI design process describe what that continuous version looks like.

FAQ