Why sprints still earn their week
Jake Knapp created the design sprint at Google and refined it at Google Ventures, and Sprint, his 2016 book with John Zeratsky and Braden Kowitz, made it a standard. The idea still holds. Take one critical product question and answer it in five days, with a small cross-functional team, a prototype and real users.
Thursday has changed the most. AI tools now let a team build a working prototype, with real data and interactions, in the time it once took to make a clickable mockup. That makes sprints more useful. It also adds a risk: a team can build something convincing enough to fool itself. The structure below keeps the week focused on learning.
Before the sprint
A sprint succeeds or fails before Monday.
- Pick a consequential question. "How should onboarding work for enterprise customers?" is a sprint question. "Improve the product" is not.
- Assemble five to seven people. Include a decision-maker with authority, an engineer who knows the constraints and someone who talks to customers every week.
- Recruit five test users now. Friday's interviews need people from your target audience, booked in advance.
- Block the calendar. Five full days. Partial attendance produces partial answers.
For remote or cross-time-zone teams, run the sprint on a shared online whiteboard and hold the core workshop hours inside the overlap window. Solo sketching on Day 2 works well asynchronously.
Day 1: Map and target
Map the user journey from first contact to the goal. Interview internal experts in short sessions: support, sales, engineering and anyone else with first-hand knowledge. Capture problems as "How might we" notes.
By the afternoon, the decider picks one target, the moment in the journey the sprint will focus on. This is a decision, not a vote. Clear authority keeps the sprint moving.
Day 2: Sketch
Start by reviewing existing solutions, from competitors and from unrelated products that solve a similar problem. Then everyone sketches alone. Group brainstorming drifts toward the loudest idea, and working alone produces more varied options.
Run Crazy 8s, eight ideas in eight minutes, then turn the strongest idea into a three-panel solution sketch. Each sketch should explain itself without its author in the room.
AI tools can help here if you use them with care. Generating a dozen layout variations in seconds widens the options. It also pulls everyone toward the same average answers. Sketch by hand first, then use AI to extend the ideas.
Day 3: Decide and storyboard
Put the sketches on the wall. Run a silent review with dot voting, then the decider makes the call. Combine ideas only when they fit together without compromise.
Then build a storyboard of ten to fifteen panels covering every screen and interaction the test user will see, from first contact to the end of the task. The storyboard is Thursday's build plan. If a detail is missing from the storyboard, it doesn't get built.
Day 4: Prototype
Build a realistic facade in one day. Split the roles: makers, a writer for real copy, an asset collector, a stitcher who joins the pieces, and an interviewer who writes Friday's script.
Modern tools change the options:
- Figma prototypes remain fastest for flows where interaction detail matters less.
- AI coding tools can produce a working web prototype with real inputs and data in hours. Use them when the question depends on realistic behaviour, such as search results or generated content.
- Real copy. Users react to words, and placeholder text ruins tests.
Scope discipline decides the day. Build only what Friday's script needs.
Day 5: Test with five users
Run five one-on-one interviews. One person moderates while the team watches from another room and takes notes on a shared grid: each user, each step, what worked and what failed.
Five users is enough to see the major patterns. Jakob Nielsen's analysis of why you only need five users shows that most usability problems appear in the first few sessions of a qualitative test. By Friday afternoon you should know whether the solution works, where it breaks and what to do next. If a question needs a different method, our guide to UX research methods that drive product decisions helps you choose one.
Running an AI discovery sprint
If the sprint question is about an AI feature, adjust three of the days.
Day 1: decide what kind of AI this is. It could be a single model call, a fixed workflow or an agent. Anthropic's Building effective agents recommends the simplest option that works, and the map is the right place to make that call. Note what a wrong output would cost the user at each step.
Day 4: fake the AI if you need to. A Wizard of Oz prototype, where a teammate plays the AI behind the interface, lets you test expectations before anyone builds a model. NN/g's guide to the method covers the setup. If you use a real model, prepare prompts that produce realistic outputs, wrong ones included.
Day 5: test the failure. Make the AI wrong on purpose at one step of the script. Watch whether users notice, how they recover and whether they trust the next answer. Trust changes after the first failure, and a sprint is the cheapest place to find out how. Our guide to UX patterns for AI interfaces lists the states worth testing.
After the sprint
A sprint produces evidence. The product comes later. In the following week:
- Write a one-page summary. The question, what you built, what users did and the decision.
- Assign owners and dates for each next step.
- Choose the next test. If the answer was clear, move to build, starting with an MVP scoped to the riskiest assumption. If it was mixed, run a smaller follow-up test on the weak step.
- Keep the recordings. Clips from Friday persuade stakeholders who weren't there.
FAQ
Can you run a design sprint remotely? Yes. Use a shared whiteboard, keep live sessions inside the time-zone overlap and move solo sketching to async time. Recruit test users in the same markets as your real customers.
Does it have to take five days? Four-day versions exist, and many teams compress Days 1 and 2. Cutting Friday's user tests defeats the purpose.
Who should be the decider? The person who would make this decision anyway, often the founder, head of product or a senior PM. If they can't attend all week, they must attend the decision points on Days 1 and 3.
What if the prototype fails the test? Count it as a good outcome. You learned in a week what could have taken months of building to discover. Go back to the map, pick the next most promising sketch and test again.
If you want to run a sprint on an AI product idea, our AI products consulting can facilitate a discovery sprint with your team that ends in a tested prototype and a build decision.