What needs to be finished first
A clearly formulated sprint goal as a long-term goal plus 2-3 linked sprint questions exists in writing and is aligned with the decider.
At least five test users from the target segment are recruited for Friday, with time slot, compensation, and task scope.
A documented JTBD statement or comparable user understanding exists, and map and sketches follow it.
What needs to be ready before start
Workshop room with two walls and whiteboard (or digital equivalent with Miro/FigJam board); pens, stickies, timer; prototyping tool (Figma, Keynote, Marvel); recording setup for Day 5; snacks and drinks (sprint is intense).
One full-time facilitator; one decider with decision authority (present Monday, Tue-Wed at least one hour, and reviewer Thursday); 4-6 sprinters from design, engineering, product, and domain experts; one prototype builder (Day 4); test users for Day 5.
Long-term goal and sprint questions; known constraints and previous attempts; expert list for Day 1 (customer, tech, business); recruiting status of test users; budget and time limits.
4-5 days (Mon 10-17, Tue 10-17, Wed 10-17, Thu 10-17, Fri 9-17)
Block room for 5 days and clear sprinter calendars. Check equipment Sunday or Monday morning. Clear walls and mark lanes for map, How-Might-We notes, and sketches. Distribute Friday test user slots into 60-min blocks.
The one question this method answers
What solution sketch for the core sprint question yields a testable prototype in four days that can be tested with real users on Day 5?
Marker: Day
| Step | Duration | Action | Hint |
|---|---|---|---|
1Day 1: Map and target | 7 h (Mon) | Set Long-term Goal and sprint questions. Build user flow map (actor left, outcome right). Run expert interviews (collect How-Might-We notes). End with decider selecting target customer and target moment on map. | If the map has more than 15 steps, scope is too broad. Decider narrows before Day 2. Cluster and vote How-Might-We notes; do not work through all. |
2Day 2: Sketch | 7 h (Tue) | Lightning demos (each person shows 3 inspirations from other products or industries). Then solo sketching in 4 steps: Notes, Ideas, Crazy 8s, Solution Sketch (3-frame storyboard, anonymous). | Solo work is core, not group brainstorming. If Day 2 shifts into discussion, results are consensus-driven moderate options rather than diverse alternatives. |
3Day 3: Decide | 7 h (Wed) | Art Museum: sketches on wall anonymously. Heat map: each person adds dots to interesting spots. Speed critique (3 min per sketch). Straw poll and final decider choice. Then storyboard into 10-15 frames for prototype. | The decider decides, not the group. If decider is uncertain, run Rumble (two prototypes in parallel) as fallback. Storyboard must be clickable at the end. |
4Day 4: Prototype | 7 h (Thu) | Assign roles: maker, stitcher, writer, asset collector, interviewer (rehearsing for Day 5). Focus on believable facade instead of full working code. End with internal dry run. | Looking realistic can be stronger than being feature-complete. If prototype does not convince in one area, Day-5 feedback there is not usable. Better fewer screens, but credible. |
5Day 5: Test | 8 h (Fri) | Five moderated 1:1 tests of 60 minutes each. Sprinters observe remotely, note in shared matrix (what works, what does not, quotes). After each test, 10-min sync. End with pattern synthesis and follow-up decision. | Five users are enough for pattern recognition, not for statistics. If conclusions are drawn after test 2, later contradictions are missed. Synthesize only after test 5. |
What comes out at the end
Sprint report document with long-term goal, sprint questions, final map with target, chosen storyboard, prototype link, test notes per user, identified patterns, and decision rationale plus owner for follow-up action.
Sprint folder with date and sprint question as title. Store all day artifacts (map photo, sketches, storyboard, prototype link, test notes). Follow-up iterations get their own sprint entry, no overwrite.
Compact working template for Design Sprint with context, input, output artifacts, and next step.
A multi-day process to understand a problem, sketch solutions, prototype, and test.
When and for what do we use this method?
Which data, observations, decisions, or materials are available?
Short notes along the runsheet.
Owner, date, and success signal.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
Long-Term Goal: In 12 months, 90% of buyers complete checkout in under 90 seconds.
Sprint Question: Can we help buyers enter payment details correctly on first attempt without external help?
Target Moment: Buyer is on payment step with card in hand.
Chosen sketch (Decider: @julia, CPO): "Inline validation with real-time example per field" (Sketch 3 by Anna).
Prototype: Figma click dummy, 14 screens, focused on payment form and error states. Link: figma.com/file/...
Test Patterns (5 users):
Decision: Pattern 1 validates the core hypothesis. Real-time preview is removed (Pattern 2). CVV helper text is replaced by visual explanation (Pattern 3). Implementation starts as 2-week sprint from 25.05., owner: @marcus.
Recognize symptoms and steer against them
Day 3 ends without clear choice and group discussion continues, storyboard delayed.
Start sprint only if decider confirms attendance. Name backup decider with same authority. If decider misses Wednesday, pause sprint rather than forcing it through.
Day 5 staffed with colleagues or friends; feedback is biased toward positivity.
Recruiting starts at least one week before. Use external recruiters (for example User Interviews, Respondent) as backup. If Friday cannot be staffed, sprint should be delayed.
Map ends with over 20 steps, sprint question covers multiple user flows.
Decider narrows target customer and moment to one point on the map. Everything else becomes follow-up sprint. Deep is better than broad.
Sprinters discuss instead of solo work, sketches become similar.
Facilitator enforces silence during sketch phase. Separate spaces if possible. Phones away. Group discussion starts only after solution sketch.
Day 4 shifts to coding instead of fake facade, makers want to build "properly".
Use prototype tools, not code. Prototype must be ready by Thursday 16:00, not after midnight. If only a visual frontend facade is possible, keep it without backend integration.
After test 2 the group is convinced, and later tests are less carefully observed.
Keep synthesis rule: no conclusions before test 5. Fill observation matrix consistently per user. Synthesize patterns only after full sample.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.