Design Sprints: Five-Day Product Innovation, Prototyping and Validation Guide

I have facilitated design sprints across organisations of every size, from early-stage startups to large enterprises, and the gap between a sprint that produces a tested prototype and one that produces a pleasant week away from delivery pressure is almost always facilitation, not the framework itself.

What this unblocks:

The argument about whether an idea will work that a room cannot settle by discussion, and the decision that keeps reopening because nobody has the authority to close it.

What the output lets you do:

Take a tested prototype and five sessions of evidence into a funding or roadmap conversation, not an opinion. It also feeds the idea evaluation matrix, and MoSCoW pass that prioritises what the sprint surfaced.

What you have at the end:

A journey map with the ranked list of what is worth solving, a ten- to fifteen-frame storyboard, a facade prototype built to test, and five user sessions with a go, no-go, or reshape read.

Where the method comes from

Jake Knapp built the design sprint inside Google Ventures between 2010 and 2012, testing the format on GV’s own portfolio companies before writing it up. Braden Kowitz, Michael Margolis, John Zeratsky and Daniel Burka each shaped a piece of it: Kowitz the design thinking, Margolis the research structure, Zeratsky and Burka the facilitation. Knapp, Zeratsky and Kowitz then published the process as a book, Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days (Simon & Schuster, 2016), turning an internal GV practice into a method any team could run.

The five-day structure belongs to them. The four-day version many teams now run as an equally standard alternative does not. Design Sprint 2.0 was published in 2017 by the design agency AJ&Smart, led by Jonathan Courtney, after the agency had run more than two hundred sprints of its own.

Knapp publicly endorsed Design Sprint 2.0 and has kept investing in it alongside the original five-day format; he contributed a substantial update to the Design Sprint Masterclass in 2024. By 2025, the Design Sprint Academy’s guidance treats the choice between the two as context-dependent rather than a compromise, and the four-day form is often the one that gets an enterprise to agree to run a sprint at all. It remains AJ&Smart’s compression, not a Google Ventures release, and getting the credit line right matters more now both formats sit on equal footing.

GV’s own four-day publication is a different tool: a four-day research sprint built by Michael Margolis to recruit and interview the five test users, designed to feed into the five-day sprint rather than replace it. People constantly conflate the two, and they answer different questions.

The design sprint

The week runs in a fixed order, and each day depends on the last. Skipping the order, or compressing two days into one, is the most common way I see teams lose the method’s value.

Prepare before day one.

State a single sprint question, precise enough that Friday’s test can answer it: “How might we reduce friction in our onboarding flow?” is a sprint question; “improve onboarding” is not. Assemble a team of seven people or fewer, and confirm one of them is the Decider, the person with the authority to choose what gets built. Book five to seven target users for Friday before the week starts: you cannot wait until you have a prototype to find testers.

Gather what the team already knows, research, analytics, competitor sightings, so day one does not reinvent insights the organisation already has. Book a room for the full week, with wall space, sticky notes and voting dots, and keep laptops and phones out of it except where a task genuinely needs one. This happens the week before day one, and a sprint that skips it starts Monday already behind.

Monday: map the problem

Interview two or three people with relevant expertise, ten to fifteen minutes each, and capture what they say on sticky notes rather than in a deck. Build a simple map of the customer’s journey from first contact with the problem to its resolution: it needs to be legible, not polished. Write “how might we” questions from what the interviews surfaced, and let the Decider narrow them down to the two or three the rest of the week will answer.

By Monday evening, the room holds a shared map of the problem and a short, ranked list of what is worth solving for one day.

Tuesday: sketch solutions

Have each person present two or three examples of how other products have solved something similar, three minutes each, so the room’s thinking widens before anyone sketches. Work alone after that, not in a group, through four steps: notes on everything gathered so far, rough individual ideas, eight one-minute variations on your strongest idea, and one detailed three-panel sketch of your best solution. A sketch needs to explain itself, since nobody talks the room through it tomorrow.

A single day of solitary sketching leaves the team with several fully worked solutions on the wall, rather than one compromise reached by committee.

Wednesday: decide and storyboard

Post every sketch on the wall without names attached, and let the team vote in silence, one dot per idea. Discuss only the sketches that draw real support, and only after the silent vote, so debate follows the room’s actual read rather than whoever speaks first.

The Decider then chooses what gets built, alone if needed; that authority stops the choice from becoming a second debate. The team spends the afternoon turning the choice into a ten-to-fifteen-frame storyboard, specific enough that Thursday’s build starts from a plan rather than a discussion. One day produces one decision and a storyboard detailed enough to build from.

Wednesday is the day I watch break first when the Decider is missing or hedging. The silent vote dissolves straight back into the committee debate it was meant to end, and no facilitator can substitute their own authority for the one the room lacks.

Thursday: build the prototype

Split the team into roles: a maker who builds the screens or artefacts, a writer for realistic copy, a stitcher who assembles the pieces into one navigable flow, an asset collector for images and icons, and an interviewer who preps Friday’s script. Build a facade real enough that a user responds naturally, not a working product: a design tool, paper and props, or a person standing in for the system all count, as long as they’re fast.

I will not take on a sprint if nobody on the team can fill the maker role. Without someone who can build the facade, Thursday turns into a discussion about what the prototype might have looked like, not a prototype you can put in front of users.

Run through the prototype yourselves before the day ends, and fix anything that would break a tester’s immersion. The day’s only output is a prototype real enough to test, and it needs to be nothing more than that.

Friday: test with five users

Run five one-to-one sessions against the prototype, each following the same structure: an introduction that sets expectations, context questions, a think-aloud walkthrough, and a debrief. Watch what a user does, not only what they say; confusion is data, not a failure to explain something.

The rest of the team observes from another room or a screen share and logs what worked, what confused people, and any quote worth keeping. Five is not an arbitrary number: Jakob Nielsen’s research with Tom Landauer, published in 1993 and popularised in Nielsen’s 2000 article “Why You Only Need to Test with 5 Users”, found that five users from a single target group surface about 85 per cent of a design’s usability problems, with each additional user mostly repeating what the last one already showed. The week ends here, with a go, no-go, or reshape decision built on what users did rather than what the room assumed.

A worked example

A seven-person team, three from product, two from engineering, one from research, and a head of product as Decider, sets the sprint question: how might we help a new signup finish account setup on the first visit? On Monday, three fifteen-minute expert interviews with support, sales, and the engineer who built the current flow produce a journey map with one clear drop-off point: a mid-flow step asking for information the product does not use for weeks. The team writes six “how might we” questions; the Decider narrows them to two.

On Tuesday, each of the seven works alone through the four sketching steps, so Wednesday’s wall holds seven distinct solutions rather than one compromise. Silent dot-voting clusters around two sketches that both remove the mid-flow step; the Decider picks one, and the team storyboards it as twelve frames that afternoon. On Thursday, five people build the facade using a design tool, leaving anything the storyboard does not need as a static, unwired screen; the interviewer spends the same afternoon booking and scripting Friday’s five sessions.

On Friday, four of the five testers reach the end of the new flow without confusion. The fifth stalls at a screen the storyboard had marked optional and treated as self-explanatory. That is the answer the week was built to produce: the direction works, one screen needs rework, and the team has a specific, evidenced fix rather than a general instinct that signup “feels long”.

Where design sprints fail

A sprint run with no Decider in the room defaults back to committee debate on Wednesday, the exact problem the role exists to prevent. I cannot substitute my own authority for that missing role, and I have watched the consensus a room reaches without one reopen the moment people disperse.

I have seen prototypes tested against the wrong five users, and it breaks the method’s own math. Nielsen’s 85 per cent figure assumes five people from one coherent target group; five people who are not that group are answering a different question than the one the sprint asked, and the result looks like a validated direction when it is not.

I push back whenever a team treats Friday’s output as validated rather than as five interviews. A sprint tells a team whether a direction survives contact with users and where it breaks. It does not tell a team what a wider launch will do.

Kevin Richard’s published critical analysis of the format argues the problem runs deeper than facilitation: weak argumentation, an irrefutability problem, and confirmation bias when the people who built the solution also watch it tested. Neutral facilitation mitigates that bias. It does not remove it, and the format has limited scope to establish whether a market for the idea exists at all.

A sprint can also produce a decision the organisation then fails to resource, and I have watched this undo a good result. The method’s speed is real, but it does not change how fast the rest of the business can move: a validated direction that nobody staffs or funds in the following weeks dies for lack of follow-through, not because the sprint got the answer wrong.

Common questions

How long does a design sprint take:

Five days, Monday to Friday, in Knapp’s original structure, or four days in AJ&Smart’s Design Sprint 2.0, now an equally standard choice rather than a shortcut. Pick five days when the team can hold a full week and the question is genuinely open. Pick four when getting an enterprise to agree to run a sprint at all is the harder problem.

How many people should be on the team:

Seven or fewer, including one Decider with the authority to choose what gets built. More than that slows every day down.

Is five users really enough to test with:

Nielsen and Landauer’s research puts the ceiling at about 85 per cent of usability problems found with five users from one target group. The number changes if the five testers aren’t from that group.

Can a design sprint run remotely:

Yes, remote sprints are now an established, distinct facilitation form, documented in the Remote Design Sprint Guide that Knapp and John Zeratsky co-created in 2020. Work moves to asynchronous prep beforehand and shorter synchronous sessions on the day, capped at around four hours rather than a full room for a week.

When is a design sprint the wrong call:

For a small, well-understood problem with an obvious solution, or for a team that already has strong user validation for the direction it is taking, a sprint spends a week answering a question nobody was asking. For ongoing product work, default to continuous discovery and deliver with regular contact with real users feeding decisions as they come up, and keep the sprint for the discrete, high-stakes question that continuous work cannot settle on its own.

What does a sprint produce:

A tested prototype, five user sessions’ worth of evidence, and a go, no-go, or reshape decision. Not a finished product, and not market validation.

Key facts, current as of September 2026