Design Sprint

Ziel

Der Design Sprint beantwortet in einer Woche eine präzise Geschäftsfrage. Das Team testet eine Lösung bei Kunden, bevor jemand sie baut. Eine Organisation, die zwischen mehreren Ideen schwankt, diskutiert sie oft monatelang. Der Design Sprint ersetzt diese Diskussion durch einen Entscheid am Mittwoch und fünf Beobachtungen am Freitag.

Der Entscheid, den er vorbereitet, betrifft die Fortsetzung des Projekts: eine getestete Lösung entwickeln, sie korrigieren oder die Idee aufgeben, bevor die Organisation in sie investiert. Die Woche liefert:

• das langfristige Ziel, die Sprint-Fragen und die Karte des Problems mit ihrem Fokus;
• die Lösungsskizzen und die Wahl des Entscheiders;
• das Storyboard und den Prototyp, der daraus entsteht;
• das Raster vom Freitag, das jede Frage vom Montag anhand dessen beantwortet, was die fünf Kunden getan haben.

Der Name führt leicht in die Irre. Der Sprint in Scrum ist eine Entwicklungsiteration von höchstens einem Monat, die ein Inkrement des Produkts liefert (Scrum Guide 2020, Abschnitt "The Sprint"). Der Design Sprint liefert einen Entscheid und einen Befund. Ein Scrum-Team kann einen Design Sprint durchführen, bevor es die ersten Einträge seines Backlogs schreibt.

Verwendung

Wann einsetzen

• Ein teurer Entscheid beruht auf einer ungetesteten Idee: fünf Tage statt monatelanger Entwicklung.
• Mehrere Abteilungen verteidigen je ihre eigene Lösung: Der Entscheider entscheidet anhand von Skizzen, danach antworten die Kunden.
• Ein neuer Service oder eine Customer Journey, die neu gestaltet werden soll: Der Fassaden-Prototyp entsteht an einem Tag.
• Eine ausgeprägte Hierarchie: Die Skizze in Einzelarbeit und die stumme Abstimmung stellen die Idee einer Berufseinsteigerin auf dieselbe Stufe wie die eines Chefs.
• Erreichbare Zielkunden: Fünf Personen mit dem passenden Profil müssen am Freitag kommen.
• Fünf volle Tage im Kalender des ganzen Teams: vor Ort oder remote auf einem digitalen Whiteboard.

Wann nicht einsetzen

• Das Problem selbst ist noch zu finden: es zuerst mit Interviews und Beobachtung eingrenzen.
• Die Lösung ist bereits beschlossen und finanziert: sie bauen, dann ihre Wirkung mit einem A/B-Test messen.
• Die Sache lässt sich in einem halben Tag klären: Ein Brainstorming mit anschliessendem Dot voting genügt.

Beschreibung

Der Design Sprint ist eine feste Abfolge. Jeder Tag beantwortet eine Frage und liefert, was der nächste Tag braucht.

Die Rollen

Der Entscheider (Decider) trägt den Entscheid in der Organisation: eine Direktorin, ein Produktverantwortlicher, eine Abteilungsleiterin. Er wählt am Montag den Fokus und am Mittwoch die Lösungen. Am Freitag beantwortet er jede Frage vom Montag mit Ja oder Nein und entscheidet über das weitere Vorgehen. Ein Design Sprint kann zwei Entscheider haben. Ein Entscheider, der nicht die ganze Woche dabei sein kann, ernennt eine Stellvertretung mit Entscheidungsbefugnis. Delegiert ein Entscheider an jemanden ohne echte Befugnis, verliert die Woche ihren Sinn: Am folgenden Montag eröffnet die tatsächliche Hierarchie die Debatte neu.

Der Moderator leitet die Woche. Er achtet auf die Zeit, führt von einer Aktivität zur nächsten und schreibt am Whiteboard mit. Wir raten, die beiden Rollen zwei Personen zu geben: Wer entscheidet, kann nicht die Zeit einer Debatte überwachen, die er selbst schlichtet.

Das Team zählt höchstens sieben Personen. Es vereint die Kompetenzen, von denen die Lösung abhängt: Finanzen, Verkauf, Kundendienst, Technik, Design. Die übrigen Fachleute befragt das Team nur am Montag.

Der Rahmen

Das Team blockiert fünf aufeinanderfolgende Tage in seinen Kalendern. Der Tag dauert von 10 bis 17 Uhr mit einer Stunde Mittagspause gegen 13 Uhr. Gegen 11.30 Uhr und gegen 15.30 Uhr macht das Team je eine kurze Pause. Der Freitag beginnt um 9 Uhr, damit die Interviews Platz finden. Während des Design Sprints schliesst jede Person ihr E-Mail-Programm und die sozialen Netzwerke. Wer Nachrichten lesen muss, verlässt den Raum oder wartet auf die Pause.

Jede Aktivität hat eine im Voraus festgelegte Dauer wie beim Timeboxing. Der Moderator zeigt einen Timer, den alle sehen. Jede Person schreibt ihre Ideen allein und still auf, danach vergleicht das Team sie. Die Methode verzichtet auf lautes Brainstorming.

Warum diese Vorgaben

Laut den Autoren halten die Entscheide ohne Entscheider nicht. Wer wählt, verantwortet auch das Budget und das weitere Vorgehen. Nach unserer Erfahrung erzeugt eine Abstimmung im Team einen Kompromiss, den danach niemand vor der Geschäftsleitung verteidigt.

Die Skizze ist anonym und die Abstimmung stumm. Das Team beurteilt die Idee also auf dem Papier, bevor es ihren Urheber hört. Redegewandtheit und Rang wiegen weniger.

Die feste Dauer verhindert, dass jemand die Entscheide des Vortags wieder aufrollt. Die fünf Kunden kommen am Freitag. Das Team entscheidet also mit dem, was es weiss.

Vor der Woche

Der Entscheider und der Moderator wählen das Problem. Sie reservieren für die Woche einen Raum mit zwei grossen Whiteboards. Für einen Remote-Design-Sprint richten sie ein digitales Whiteboard ein. Sie reservieren auch einen zweiten Raum für die Interviews am Freitag. Sie laden die Fachleute für den Montag ein. Während der Woche rekrutiert eine Person die fünf Kunden und setzt dafür ein bis zwei Stunden pro Tag ein. Sie stützt sich auf einen Auswahlfragebogen, der das gesuchte Profil nicht verrät. Bei einem seltenen Profil beginnen wir vor dem Montag: Fünf Personen zu finden, die an einem bestimmten Freitag frei sind, dauert länger als vier Tage.

Montag: kartieren und einen Fokus wählen

Das Team beginnt mit dem Ende. Es schreibt das langfristige Ziel: wo die Organisation dank diesem Projekt in sechs Monaten, einem Jahr oder fünf Jahren stehen will. Der Satz ist optimistisch und passt auf eine Zeile.

Danach sucht das Team, woran das Ziel scheitern könnte. Jeder Grund des Scheiterns wird zu einer Sprint-Frage: "Versteht der Kunde die Tragbarkeitsrechnung ohne Berater?" Der Freitag muss sie beantworten.

Das Team zeichnet die Karte des Problems. Links stehen die Akteure: die Kunden und die übrigen Beteiligten. Rechts steht das Ende: Der Kunde hat erreicht, was er wollte. Dazwischen verbinden Pfeile fünf bis fünfzehn Schritte. Die Karte ist einfacher als eine Customer Journey Map und hält weder Emotionen noch Kontaktpunkte fest. Mit ihr wählt das Team, worauf es die Woche konzentriert.

Das Team befragt die Fachleute nacheinander. Jede Person erzählt, was sie über das Problem weiss: ein Verkaufsberater, eine Supportleiterin, ein Jurist, eine Entwicklerin. Jedes Gespräch dauert 15 bis 30 Minuten. Die ganze Reihe nimmt zwei bis drei Stunden in Anspruch. Das Team korrigiert die Karte laufend nach dem, was die Fachleute erzählen. Gleichzeitig schreibt jede Person das Gehörte als Wie-könnten-wir-Notizen auf. Das Team klebt diese Notizen an die Wand, gruppiert sie nach Thema, ordnet sie per Dot voting und setzt die meistgewählten auf die Karte. Für diese Abstimmung hat jede Person zwei Stimmen.

Zum Schluss wählt der Entscheider den Fokus: einen Kunden und einen Moment der Karte. Der Rest der Woche gilt nur diesem Moment.

Dienstag: suchen, dann allein skizzieren

Der Vormittag beginnt mit den Kurzdemos (Lightning Demos). Jedes Mitglied stellt in drei Minuten eine bestehende Lösung vor, die für den Fokus relevant ist: ein Konkurrenzprodukt, einen Service aus einer anderen Branche, eine im Unternehmen aufgegebene Idee. Der Moderator zeichnet das nützliche Element jeder Demo ans Whiteboard. Das Team baut seine eigenen Lösungen auf diesen Elementen auf.

Vor dem Mittagessen legt das Team fest, wer welchen Teil der Karte skizziert (divide or swarm). Bei einem breiten Fokus teilt es jeden Teil einer Person zu. Bei einem engen Fokus skizzieren alle denselben Teil.

Am Nachmittag skizziert jede Person allein in vier Schritten:

1. die Notizen (20 Minuten): Jede Person liest die Notizen an der Wand noch einmal und schreibt ab, was zählt;
2. die Ideen (20 Minuten): schnelle Kritzeleien für sich selbst;
3. die Crazy 8s (8 Minuten): acht Varianten der besten Idee in je einer Minute;
4. die Lösungsskizze (30 bis 90 Minuten): die ausgearbeitete Lösung in drei Bildfeldern. Sie ist anonym und so klar, dass sie sich ohne ihren Urheber lesen lässt.

Die Skizze darf unbeholfen sein. Ihre Texte müssen ausformuliert sein: Der Texter übernimmt sie am Donnerstag.

Mittwoch: entscheiden

Am Morgen prüft das Team die Skizzen ohne offene Debatte. Die Schritte folgen in dieser Reihenfolge:

1. das Museum (Art Museum): Das Team hängt die Skizzen wie in einer Galerie an die Wand;
2. die Heatmap (Heat Map): Jede Person liest alle Skizzen still und klebt einen bis drei kleine Klebepunkte neben jeden Teil, der sie interessiert;
3. die Schnellkritik (Speed Critique): drei Minuten pro Skizze. Das Team bespricht die Teile, die die Klebepunkte markiert haben. Der Moderator notiert die auffälligen Ideen und die Einwände. Am Ende sagt der Urheber, was das Team übersehen hat;
4. die Probeabstimmung (straw poll): Jede Person setzt eine Stimme auf die Lösung, die sie bevorzugt;
5. der Supervote: Der Entscheider setzt drei grosse Klebepunkte mit seinen Initialen auf die Lösungen, die er auswählt.

Der Entscheider wählt eine oder mehrere Lösungen. Widersprechen sie sich, baut das Team zwei oder drei konkurrierende Prototypen und testet sie am Freitag: Das ist der Rumble. Die übrigen Skizzen warten auf einer Liste für später.

Die Heatmap und die beiden Abstimmungen wenden Dot voting an. Die Abstimmung des Teams informiert den Entscheider, ohne ihn zu binden.

Am Nachmittag zeichnet das Team das Storyboard auf ein Whiteboard: ein Raster aus etwa fünfzehn Comic-Feldern. Es erzählt von Anfang bis Ende, was der Kunde am Freitag erlebt. Das erste Feld ist die Eröffnungsszene: wie der Kunde dem Produkt gewöhnlich begegnet. Das Storyboard legt den Inhalt des Prototyps fest. Eine Idee, die darin fehlt, baut das Team am Donnerstag nicht.

Donnerstag: eine Fassade als Prototyp bauen

Der Prototyp muss nur für die Dauer eines Interviews echt wirken. GV fasst dieses Prinzip mit "fake it" zusammen. Je nach Lösung ist die Fassade eine Folge klickbarer Bildschirme, eine Webseite, eine Broschüre oder ein Schaltergespräch, das ein Kollege nach Skript spielt. Es ist ein Wegwerf-Prototyp: Das Team wirft ihn nach dem Test weg. Die anderen Formen von Mock-ups finden Sie unter Prototyping.

Das Team teilt die Arbeit nach Rollen auf. Die Macher (Makers) bauen die Bildschirme oder die Teile. Der Verbinder (Stitcher) fügt die Teile zusammen und achtet auf ihre Stimmigkeit. Der Texter (Writer) schreibt die Texte. Der Sammler (Asset Collector) trägt Bilder, Logos und Inhalte zusammen. Der Interviewer bereitet anhand des Storyboards und der Fragen vom Montag den Interviewleitfaden für den Freitag vor.

Gegen 15 Uhr geht das Team den Prototyp in der Reihenfolge des Storyboards durch. Der Interviewer und der Entscheider sind dabei. Diese Probe findet den toten Link und den Platzhaltertext, bevor ein Kunde sie sieht.

Freitag: mit fünf Kunden testen

Der Interviewer empfängt die fünf Kunden des Zielprofils nacheinander. Die Autoren gliedern das Interview in fünf Akte. Der Interviewer schafft eine entspannte Atmosphäre, fragt den Kunden nach seinem Kontext und stellt ihm den Prototyp vor. Dann bittet er ihn, Aufgaben zu lösen und dabei laut zu denken. Zum Schluss holt er die Eindrücke des Kunden ein. Der Interviewer verkauft die Lösung nicht. Er fragt den Kunden, was er sucht, was er zu sehen glaubt und was er als Nächstes tun würde.

Das übrige Team verfolgt das Interview per Video aus einem anderen Raum. Ton und Bild gehen nur vom Interviewraum in den Teamraum. Während des Interviews schreibt jede Person auf Haftnotizen, was der Kunde tut und sagt. Ein Raster am Whiteboard zeigt die fünf Kunden in den Spalten und die Fragen vom Montag oder die Hypothesen des Prototyps in den Zeilen. Nach jedem Interview stimmt jede Person für diesen Kunden bei jeder Frage mit Ja oder Nein. Der Entscheider wägt diese Stimmen ab und entscheidet über das Feld. Am Ende des Tages gibt er pro Frage ein einziges Ja oder Nein. Danach schreibt jede Person ihre spontane Einschätzung und die nächsten Schritte auf, die sie vorschlägt. Der Entscheider entscheidet über das weitere Vorgehen.

Das Interview zur Elizitation befragt einen Stakeholder nach seinen Bedürfnissen. Das Interview am Freitag beobachtet, was ein Kunde mit einer Lösung tut.

Die Zahl fünf stammt aus Usability-Tests. Jakob Nielsen hat 2000 berechnet, dass fünf Nutzer rund 85% der Usability-Probleme einer Oberfläche finden und ein einzelner Nutzer 31%. Die Rechnung gilt für vergleichbare Nutzer. Zwei sehr unterschiedliche Kundenprofile verlangen je drei oder vier Personen. Nielsen spricht nicht vom Design Sprint.

Woran ein Design Sprint scheitert

Das Problem während der Woche wählen. Ein Team, das den Montag mit der Frage verbringt, woran es arbeiten soll, hat am Mittwoch keinen Fokus.

Ein Team, das kommt und geht. Wer den Montag verpasst, stimmt am Mittwoch über eine Karte ab, die er nicht mitgebaut hat. Er rollt bereits entschiedene Punkte wieder auf.

Den Prototyp polieren. Ein Team, das einen sorgfältig ausgearbeiteten Prototyp will, wird am Donnerstag nicht fertig. Der Kunde am Freitag reagiert auf Inhalt und Ablauf. Den Feinschliff bemerkt er nicht.

Fünf Interviews als Beweis lesen. Fünf Kunden zeigen Hindernisse und Missverständnisse. Sie messen weder einen Marktanteil noch eine Kaufabsicht. Ein Design Sprint liefert einen ersten Befund über fünf Personen. Nielsen empfiehlt mehrere kleine Tests statt eines einzigen grossen. Ein zweiter Test an einem korrigierten Prototyp bestätigt oder widerlegt den ersten.

Ein bewiesenes Ergebnis versprechen. Die veröffentlichten Fälle stammen vor allem von den Autoren der Methode und von Teams, die sie angewandt haben. Wir kennen keine kontrollierte Studie, die einen Design Sprint mit einer anderen Art der Entscheidung vergleicht. Die Methode garantiert nur einen Entscheid und einen Test in einer Woche.

KI-Überlegungen

Vor der Woche bereitet ein Assistent die Kurzdemos vor. Er listet Lösungen auf, die ein verwandtes Problem in anderen Branchen behandeln. Jedes Mitglied prüft danach die Lösung, die es vorstellt, am Produkt selbst. Ein Assistent beschreibt manchmal eine Funktion, die es nicht gibt.

Am Montag transkribiert der Assistent die Gespräche mit den Fachleuten und zieht daraus eine Übersicht pro Schritt der Karte. Das Team behält seine eigenen Wie-könnten-wir-Notizen. Eine von der KI erzeugte Liste würde das Zuhören ersetzen, aus dem sie entstehen.

Am Donnerstag füllt der Assistent die Fassade. Er verfasst die Bildschirmtexte, die Fehlermeldungen und die Bestätigungs-E-Mails. Er erzeugt die Illustrationsbilder und die fiktiven Daten. Der Texter liest jeden Text gegen. Ein vager Text im Prototyp löst am Freitag eine vage Reaktion aus.

Am Freitag transkribiert der Assistent die Interviews und schlägt vor, wie die Zitate ins Raster einzuordnen sind. Das Team vergleicht diese Einordnung mit dem, was es gesehen hat. Ein Zögern von zwanzig Sekunden vor einer Schaltfläche steht in keinem Transkript.

Die Einzelskizze vom Dienstag bleibt menschlich. Skizzen aus demselben Modell gleichen sich. Die Heatmap hat dann nichts mehr zu vergleichen. Die Wahl des Entscheiders und die Deutung der Reaktionen vom Freitag bleiben ebenfalls menschlich.

Die Aufnahmen zeigen identifizierbare Kunden. Der Interviewer holt ihre schriftliche Einwilligung ein, bevor er aufnimmt. Keine Aufnahme geht an einen KI-Dienst, den die Organisation nicht zugelassen hat.

Beispiele

Das folgende Raster schliesst einen Design Sprint ab, den eine Kantonalbank zu einer Online-Finanzierungszusage für Hypotheken durchgeführt hat.

Der Entscheider beantwortet die dritte Frage mit Nein. Den Grund hat der Prototyp geschaffen: Der Text sagt nicht, wozu die Zusage die Bank verpflichtet. Der Entscheider lässt diesen Text neu schreiben und vor jeder Entwicklung erneut testen.

Visualisierungen

Das Schema der Woche zeigt, was jeder Tag für den nächsten liefert. Es markiert die drei Momente, in denen der Entscheider entscheidet. Es zeigt auch, wie sich die vielen Ideen des Dienstags auf die ausgewählten und am Donnerstag prototypisierten Lösungen verengen. Die Karte vom Montag folgt einem Online-Antrag auf eine Finanzierungszusage für Hypotheken und zeigt den Fokus, den der Entscheider eingekreist hat. Das Schema vom Mittwoch trennt, was das Team signalisiert, von dem, was der Entscheider wählt. Das Raster vom Freitag zeigt das Arbeitsergebnis.

Kosten

Werkzeuge

Vor Ort braucht das Team zwei grosse Whiteboards, gelbe Haftnotizen, Filzstifte, Klebepunkte in zwei Grössen und einen Timer, den alle sehen. Jede Person skizziert auf A4-Blättern.

Am Donnerstag hängt das Prototyping-Werkzeug von der Fassade ab. Die Autoren raten von den Werkzeugen des Alltags ab: Diese sind auf Qualität ausgelegt. Stattdessen verlangen die Autoren einfache, schnelle und flexible Werkzeuge. Für klickbare Bildschirme genügt eine Präsentationssoftware wie Keynote oder PowerPoint. Figma eignet sich, wenn es ein Werkzeug für schnelle Skizzen bleibt. Eine Broschüre lässt sich in einer Textverarbeitung gestalten.

Am Freitag überträgt ein Videokonferenz-Werkzeug das Interview in den Beobachtungsraum. Die Autoren führen die meisten ihrer Design Sprints remote durch. Bei einem Remote-Sprint ersetzt ein digitales Whiteboard wie Miro oder Mural die Wände. Ein gemeinsamer Raum bietet zusätzlich die nebeneinander aufgehängten Skizzen, die geteilte Stille und die Aufmerksamkeit aller.

Quellen

Keine Normungsorganisation definiert den Design Sprint. Die Methode stammt von ihren Autoren bei GV.

• Knapp, Jake, Zeratsky, John und Kowitz, Braden (2016), Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days, Simon & Schuster: das Ursprungswerk der Methode.
• Knapp, Jake und Zeratsky, John, Design Sprint: How to solve big problems and test new ideas in just five days, Character Capital: die Checkliste der Autoren Stunde für Stunde, von der Wahl des Entscheiders bis zum Raster vom Freitag.
• GV, The Design Sprint: die offizielle Zusammenfassung der Woche, vom langfristigen Ziel am Montag bis zu den Interviews am Freitag.
• Character, Sprint: die Seite zum Buch, die Jake Knapp und John Zeratsky betreuen. Sie datiert die Entstehung der Methode bei Google auf 2010.
• Nielsen, Jakob (2000), Why You Only Need to Test with 5 Users, Nielsen Norman Group: der Anteil der Usability-Probleme, den ein Nutzer und den fünf Nutzer finden; die Beschränkung der Rechnung auf vergleichbare Nutzer.
• Schwaber, Ken und Sutherland, Jeff (2020), The Scrum Guide, Abschnitt "The Sprint": der Sprint in Scrum und seine Dauer von höchstens einem Monat.