Was vorher fertig sein muss
Ein klar formuliertes Sprint-Ziel als Long-Term Goal plus 2-3 zugehörige Sprint Questions liegen schriftlich vor, abgestimmt mit dem Decider.
Mindestens fünf Testnutzer aus der Zielgruppe sind für Freitag rekrutiert, mit Termin, Vergütung und Aufgabenrahmen.
Ein dokumentiertes JTBD-Statement oder vergleichbares Nutzerverständnis existiert, an dem sich die Map und die Sketches orientieren.
Was vor Start vorliegen muss
Workshop-Raum mit zwei Wänden und Whiteboard (oder digitales Äquivalent mit Miro/FigJam-Board); Stifte, Stickies, Timer; Prototyping-Tool (Figma, Keynote, Marvel); Aufnahme-Setup für Tag 5; Snacks und Getränke (Sprint ist anstrengend).
Ein Facilitator (full-time); ein Decider mit Entscheidungsbefugnis (anwesend Mo, Di-Mi mindestens 1 h, Do Reviewer); 4-6 Sprinter aus Design, Engineering, Product, Domain-Experten; ein Prototyper (Tag 4); Testnutzer für Tag 5.
Long-Term Goal und Sprint Questions; bekannte Constraints und vorherige Lösungsversuche; Expertenliste für Tag 1 (Customer, Tech, Business); Recruiting-Status der Testnutzer; Budget und Zeitlimit.
4-5 Tage (Mo 10-17, Di 10-17, Mi 10-17, Do 10-17, Fr 9-17)
Raum für 5 Tage blocken, alle Sprinter-Kalender clearen. Equipment am Sonntag oder Montag früh prüfen. Walls leer und mit Bahnen für Map, How-Might-We-Notizen und Sketches markiert. Testnutzer-Termine in 60-min-Slots auf Freitag verteilt.
Die eine Frage, die diese Methode beantwortet
Welche Lösungsskizze für die zentrale Sprint-Frage liefert in 4 Tagen einen testbaren Prototyp, der am 5. Tag bei echten Nutzern reagiert?
Marker: Tag
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Tag 1: Map und Target | 7 h (Mo) | Long-Term Goal und Sprint Questions setzen. Map des Nutzerflusses erstellen (links Actor, rechts Outcome). Experten-Interviews (How-Might-We-Notizen sammeln). Am Ende Decider wählt Target Customer und Target Moment auf der Map. | Wenn Map am Ende mehr als 15 Schritte hat, ist Scope zu breit. Decider kürzt vor Tag 2. How-Might-We-Notizen werden geclustert und gevotet, nicht alle bearbeitet. |
2Tag 2: Sketch | 7 h (Di) | Lightning Demos (jede Person zeigt 3 Inspirationen aus anderen Produkten/Branchen). Danach Solo-Sketching in 4 Schritten: Notes, Ideas, Crazy 8s, Solution Sketch (3-Frame-Storyboard, anonym). | Solo-Arbeit ist Kern, kein Brainstorming-Tisch. Wer in Tag 2 in Gruppendiskussion abrutscht, produziert konsensgetriebene mittelmäßige Sketches statt diverser Optionen. |
3Tag 3: Decide | 7 h (Mi) | Art Museum (Sketches anonym an Wand). Heat Map (jeder klebt Dots auf interessante Stellen). Speed Critique (3 min pro Sketch). Straw Poll und finale Decider-Entscheidung. Anschließend Storyboard auf 10-15 Frames für den Prototyp. | Decider entscheidet, nicht die Gruppe. Wenn Decider unsicher ist, „Rumble“ (zwei Prototypen parallel) als Notfall-Option. Storyboard muss am Ende klickbar planbar sein. |
4Tag 4: Prototype | 7 h (Do) | Rollen verteilen: Maker (baut), Stitcher (verbindet Screens), Writer (Microcopy), Asset Collector, Interviewer (probt für Tag 5). Fokus auf Fake-Fassade, nicht funktionierender Code. Am Ende Test-Run mit einem internen Probanden. | Realistisch wirken schlägt vollständig sein. Wenn der Prototyp in einem Bereich nicht überzeugt, ist Tag-5-Feedback dort unbrauchbar. Lieber weniger Screens, dafür glaubhaft. |
5Tag 5: Test | 8 h (Fr) | Fünf moderierte 1:1-Tests à 60 min. Sprinter beobachten remote, notieren in geteiltem Raster (was funktioniert, was nicht, Zitate). Nach jedem Test 10 min Sync. Am Ende Pattern-Synthese und Entscheidung für Folgeaktion. | Fünf Nutzer reichen für Pattern-Erkennung, nicht für Statistik. Wer nach Test 2 schon Schlüsse zieht, übersieht spätere Widersprüche. Erst nach Test 5 synthetisieren. |
Was am Ende rauskommt
Sprint-Report-Dokument mit Long-Term Goal, Sprint Questions, finaler Map mit Target, gewähltem Storyboard, Prototyp-Link, Test-Notizen pro Nutzer, identifizierten Patterns und Decision Rationale plus Owner für Folgeaktion.
Sprint-Ordner mit Datum und Sprint-Frage als Titel. Alle Tag-Artefakte (Map-Foto, Sketches, Storyboard, Prototyp-Link, Test-Notizen) versioniert ablegen. Folge-Iterationen bekommen eigenen Sprint-Eintrag, keine Überschreibung.
Kompakte Arbeitsvorlage für Design Sprint mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Design Sprint Arbeitsvorlage
## Ziel
Mehrtagiger Prozess, um ein Problem zu verstehen, Lösungen zu skizzieren, zu prototypen und zu testen.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- Prototype:
- Test Findings:
- Decision Rationale:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## Design Sprint Report — Checkout-Abbruch reduzieren (18.05.-22.05.2026)
**Long-Term Goal**: In 12 Monaten haben 90% der Käufer einen reibungslosen Checkout in unter 90 s.
**Sprint Question**: Können wir Käufer dazu bringen, ihre Zahlungsdaten beim ersten Versuch korrekt einzugeben, ohne externe Hilfe?
**Target Moment**: Käufer ist auf Zahlungsschritt, hat Kreditkarte in der Hand.
**Gewählter Sketch** (Decider: @julia, CPO): „Inline-Validierung mit Echtzeit-Beispiel pro Feld“ (Sketch 3 von Anna).
**Prototyp**: Figma-Klickdummy, 14 Screens, fokussiert auf Zahlungsformular und Fehlerstati. Link: figma.com/file/...
**Test-Patterns (5 Nutzer)**:
1. Alle 5 Nutzer schafften den Zahlungsschritt ohne Hilfe (vorher 2/5).
2. 3/5 verwirrt durch die Echtzeit-Vorschau der Kartennummer („zeigt das jemand anderem?“).
3. CVV-Feld-Hilfetext nicht gelesen, 4/5 brauchten zweiten Anlauf.
**Decision**: Pattern 1 validiert die Hauptthese. Echtzeit-Vorschau wird entfernt (Pattern 2). CVV-Hilfetext wird durch Visual ersetzt (Pattern 3). Implementierung als 2-Wochen-Sprint ab 25.05., Owner: @marcus.Symptome erkennen, gegensteuern
Tag 3 endet ohne klare Auswahl, Gruppe diskutiert weiter, Storyboard verzögert sich.
Sprint nur starten, wenn Decider verbindlich zugesagt hat. Ersatz-Decider mit derselben Autorität vorab benennen. Wenn Decider am Mittwoch ausfällt, Sprint pausieren statt durchwurschteln.
Tag 5 wird mit Kollegen oder Freunden besetzt, Feedback ist gefälligkeitsverzerrt.
Recruiting startet in Woche -1, nicht am Donnerstag. Externe Recruiter (z. B. User Interviews, Respondent) als Backup. Wenn Freitag nicht besetzt werden kann, Sprint verschieben.
Map am Ende von Tag 1 hat über 20 Schritte, Sprint Question deckt mehrere Nutzerflüsse ab.
Decider verengt Target Customer und Target Moment auf einen einzigen Punkt der Map. Alles andere wird Followup-Sprint. Lieber tief als breit.
Sprinter sitzen in Diskussion statt Solo-Arbeit, alle Sketches sehen ähnlich aus.
Facilitator erzwingt Stille während Sketch-Phase. Räumliche Trennung wenn möglich. Telefone weg. Erst nach Solution Sketch wird wieder geredet.
Tag 4 läuft in Code statt Fake-Fassade, Maker wollen „richtig bauen“.
Klicktrack-Tools statt Code. Prototyp muss am Donnerstag 16:00 stehen, nicht „bis Mitternacht“. Wenn nur eine Fassade in Frontend-Code geht, dann ohne Backend-Anschluss.
Nach Test 2 ist die Gruppe überzeugt, weitere Tests werden weniger sorgfältig beobachtet.
Synthese-Regel: keine Schlüsse vor Test 5. Beobachtungs-Raster strikt befüllen pro Nutzer. Patterns erst nach komplettem Sample.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.