Preparation
01 · Assemble the sprint team
- 5–7 people with different areas of expertise relevant to the challenge. Include: a decision-maker (who can commit the organization), a subject matter expert, a customer/user representative, a designer or creative thinker, and a facilitator (the "Sprint Master").
- Block the entire week for the core team. Partial participation breaks the sprint.
02 · Recruit five users for Friday testing
- Five is the magic number: Jakob Nielsen's research shows that 5 users reveal 85% of usability issues. Recruit from the actual target population, not team members or friends.
- Schedule 1-hour individual interviews with each user, spread across Friday afternoon.
03 · Prepare the sprint room
- Large whiteboard or paper-covered walls. No tables — participants work standing and moving.
- Post-it notes in multiple colors, markers, printed templates.
- A timer. Time pressure is a core Sprint mechanic — it forces decisions.
Step-by-step instructions
1
Monday — Map and target
- Long-term goal (30 min): What does success look like in 6 months or 2 years? Start with the end in mind.
- Sprint questions (30 min): What questions does this sprint need to answer? What could go wrong? Reframe risks as questions: "Will users understand the onboarding process?"
- Map (1 hour): Draw a simple diagram of the user journey — actors on the left, goal on the right, key steps in between. Keep it to one page.
- Expert interviews (2–3 hours): Invite 3–5 internal experts for 15–20 minute conversations each. Team members take "How Might We..." notes throughout. At the end, vote on the most important HMW notes.
- Pick a target (30 min): The Decider picks one moment on the map — the most critical, riskiest, or most promising — as the sprint's focus.
2
Tuesday — Sketch
- Lightning Demos (1.5 hours): Each team member finds 3 examples of existing solutions to similar problems (from any industry) and presents them in 3 minutes each. Take inspiration notes on the whiteboard.
- Individual sketching (4 steps, 2 hours): Working alone and in silence, each person sketches their solution concept through four progressive stages: Notes → Ideas → Crazy 8s (fold paper into 8 panels, sketch 8 variations in 8 minutes) → Solution sketch (3-panel storyboard of their best idea).
- The individual + silent approach prevents groupthink and ensures all ideas are generated before any are evaluated.
3
Wednesday — Decide
- Art museum review (30 min): Pin all solution sketches anonymously on the wall. Team walks silently and places dot stickers on parts they find interesting.
- Speed critique (30 min): Facilitator narrates each sketch while the artist stays silent. Team adds dots and raises concerns.
- Straw poll + Decider vote (15 min): Each person votes for their preferred concept. The Decider makes the final call — they can follow the vote or override it, but they decide.
- Storyboard (2 hours): Map out the prototype in 10–15 frames: every step the user will take, every screen or interaction. This becomes the blueprint for Thursday's build.
4
Thursday — Prototype
- Build a realistic but fake prototype — not a working product, but something convincing enough that users respond to it as if it were real.
- Divide roles: Makers (build components), Stitcher (assembles), Writer (handles copy), Asset collector (gathers images and icons), Interviewer (prepares Friday's test script).
- The prototype must be complete by end of Thursday. Cut scope rather than work late — a rough complete prototype is more testable than a polished incomplete one.
5
Friday — Test
- Five individual 1-hour interviews. The team watches from a separate room via screen share or video, taking notes on a shared document divided into 5 columns (one per user).
- The interviewer uses a standard script but follows the user's experience without coaching. Task-based: "Could you show me how you would [task]?"
- Debrief (1 hour): After all five interviews, team reviews patterns across users. What surprised them? What patterns appeared in 3+ users? What validated assumptions? What refuted them?
- Output: a clear verdict — the core idea works / doesn't work / works with modifications — and specific next steps.
Materials
Large whiteboard or paper-covered walls
Post-it notes in multiple colors, markers
Timer (visible to all)
Printed sprint templates (voting dots, HMW sheets, storyboard frames)
Prototype tools: Figma, Keynote, or even paper for low-fidelity prototypes
Screen recording or video setup for user testing
Digital tools
Practical recommendations
No laptops during sprint activities. Phones and laptops fragment attention — the sprint requires full presence. Designate specific "laptop moments" for research only.
The Decider must be present and empowered. A sprint without a real decision-maker produces sketches that get reviewed by someone who wasn't there. The Decider must be in the room and able to commit the organization.
Don't prototype too early. The common failure is jumping to Thursday's prototype mindset on Tuesday. Monday and Tuesday exist to maximize the diversity of ideas before converging — skipping this produces a Sprint that tests the first idea rather than the best one.
Five users is the non-negotiable minimum for Friday. Fewer than five produces unreliable patterns. More than five on the same Friday is usually unnecessary and exhausting.
Virtual sprints work but need extra structure. Remote sprints using Miro or MURAL are effective — but require more explicit time boundaries, mandatory cameras on, and a stronger facilitation hand to compensate for the loss of spatial cues.
The Sprint process is a starting point, not a script. Jake Knapp's book documents a version that works — but sprint practitioners adapt it constantly. The core is the sequence of diverge-converge-test, not the specific exercises.
Inspiration
Application examples:
- Product development: A fintech startup uses a Design Sprint to test three different onboarding flows before committing to build any of them. Friday's testing reveals that users abandon at the same step in all three — a problem in the product concept, not the design.
- Public innovation: A government agency runs a Sprint to redesign a benefits application form. Five users on Friday reveal that the primary confusion point is a single ambiguous question — which is fixed in the next version without a full redesign.
- Education: A university learning design team runs a Sprint to prototype a new blended learning experience before committing to course development. Testing reveals that the proposed "autonomous" component causes anxiety in students who need more structure — reshaping the final design.
- NGO: An NGO uses a Sprint to test a community data-collection tool before deployment in the field, discovering that the assumed smartphone literacy among field workers doesn't match reality — pivoting to a simpler interface.
Consulted sources
- Knapp, J., Zeratsky, J. & Kowitz, B. (2016). Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days. Simon & Schuster.
- Nielsen, J. & Landauer, T. K. (1993). A mathematical model of the finding of usability problems. Proceedings of ACM INTERCHI, 206–213.
- Banfield, R., Lombardo, T. & Wax, T. (2015). Design Sprint: A Practical Guidebook for Building Great Digital Products. O'Reilly Media.
