strivestudio
Berlin und Hamburg

Design Sprint

Ein Design Sprint verdichtet Wochen auf Tage.

Fünf Phasen, ein Team, am Ende ein Prototyp, den echte Menschen benutzt haben. Kein Konzeptpapier, das nach drei Monaten niemand mehr anfasst.

~8 Min5 Phasen3 Formate

Das Format ersetzt Abstimmung durch Beobachtung. Statt zu diskutieren, welche Variante die bessere wäre, baut das Team eine und legt sie echten Menschen vor. Danach diskutiert das Team nicht mehr darüber, wer recht hat. Es hat gesehen, was passiert.

Jake Knapp entwickelte den Design Sprint ab 2010 bei Google. 2012 brachte er das Format zu Google Ventures. Mit seinem Buch „Sprint“ wurde es 2016 bekannt. Die Idee: Eine Produktfrage wird innerhalb einer Arbeitswoche bis zum getesteten Prototyp geführt.

Der Ablauf funktioniert bis heute. Eine Annahme dahinter gilt aber nicht mehr: 2010 brauchte ein lauffähiger Prototyp noch Wochen. Heute können wir ihn an einem Nachmittag bauen. Dadurch verändert sich vor allem der vierte Tag. Was sich konkret verschiebt →

Ablauf

Fünf Phasen, nicht mehr fünf Tage.

Die fünf Aufgaben bleiben: verstehen, skizzieren, entscheiden, bauen und testen. Sie müssen aber nicht mehr je einen ganzen Tag belegen. Weil funktionale Prototypen schneller entstehen, können wir innerhalb einer Woche mehrfach bauen und testen. Jede Runde liefert neues Verhalten und schärft die nächste Frage.

  1. Verstehen

    Das Team sammelt, was es über Problem, Nutzer:innen und Markt bereits weiß. Fachleute ergänzen kurze Inputs. Daraus formuliert das Team eine schriftliche Sprint-Frage, die am Ende beantwortet werden soll.

  2. Skizzieren

    Jede Person entwirft still ihre eigene Lösung. Keine Gruppendiskussion, keine Moderation zur Konsensfindung. Das ist der Teil, an dem die meisten Workshops scheitern: gemeinsames Brainstorming produziert den kleinsten gemeinsamen Nenner, paralleles Skizzieren produziert Alternativen.

  3. Entscheiden

    Das Team bewertet die Skizzen mit einer strukturierten Abstimmung. So entscheidet nicht die lauteste Stimme. Aus der gewählten Richtung entsteht ein Storyboard, das den Prototyp Schritt für Schritt beschreibt.

  4. Prototyp

    Das Storyboard wird in eine testbare Fassade übersetzt. Sie muss echt genug wirken, um im Test ernst genommen zu werden, und nicht mehr. Was hinter der Oberfläche liegt, bleibt leer.

  5. Testen

    Fünf bis sechs Menschen aus der Zielgruppe arbeiten mit dem Prototyp. Das Team beobachtet sie dabei. Danach ist klar, welche Teile der Hypothese tragen und welche nicht. Die Antwort kommt nach Tagen, nicht nach Quartalen.

Formate

Was du brauchst, hängt an der Frage.

Grenzen

Die Fassade war eine Kostenentscheidung.

Was eine Fassade beantworten kann

Der Prototyp am vierten Tag ist eine Fassade. Vorne eine Oberfläche, die echt aussieht, dahinter nichts. Am fünften Tag legt das Team sie fünf Testpersonen vor und fragt, was sie damit machen würden. Die Antwort ist eine Absichtserklärung, kein Verhalten. Für Konzeptfragen reicht das: Welche Variante ist verständlicher? Wo hakt der Ablauf? Welche Worte funktionieren?

Wo ihre Aussagekraft endet

Für Verhaltensfragen trägt es nicht. Ob Menschen wiederkommen, etwas in der dritten Woche noch benutzen oder dafür bezahlen, zeigt nur funktionale Software im echten Kontext.

In dieser Lücke sterben die meisten Produktvorhaben. Zwischen „die Testpersonen mochten den Prototyp“ und „Menschen benutzen das Produkt“ liegt alles, was eine Fassade nicht zeigen kann: ob jemand die App an einem stressigen Dienstagmorgen öffnet, ob er morgen wiederkommt, ob er einer Kollegin davon erzählt. In einem Sportprojekt haben wir das von außen gesehen. Sauberer Prozess, gründliche Recherche, intern validiert, alle einig, Produkt live. Als wir danach Nutzertests gefahren haben, saß eine Nutzerin vor ihrem Ergebnis-Screen.

„Okay, und was mache ich jetzt damit?“
Eine Nutzerin im Test, vor ihrem Ergebnis-Screen

Das Produkt tat genau, was es sollte. Es half nur niemandem weiter. Der Geschäftsführer hat es später so zusammengefasst: Wir haben ein Werkzeug hingestellt, wo eine Lösung gebraucht wurde. Die Technik war nicht falsch. Der echte Bedarf war nie mit einem echten Produkt im echten Kontext getestet worden.

Wichtig ist, warum das Format so gebaut wurde. Die Fassade war nie eine methodische Entscheidung, sondern eine ökonomische: An einem Tag ließ sich nichts bauen, das wirklich läuft. Genau diese Annahme hat sich in den letzten Jahren aufgelöst.

Was sich ändert

Vibe Coding verschiebt den vierten Tag.

Vibe Coding heißt: Du beschreibst, was die Software tun soll, und erhältst lauffähigen Code. Dadurch wird im Sprint vor allem das Bauen günstiger. Ein kleines Team kann einen funktionalen Prototyp umsetzen, statt zuerst ein Anforderungsdokument an die Entwicklung zu geben. Die alte Fassade ist damit oft nicht mehr nötig.

Würden Menschen es nutzen? Oder tun sie es wirklich?

Der klassische Prototyp sammelt Absichtserklärungen im Interview. Ein Behavioral Prototype zeigt Verhalten im Alltag.

Klassischer Prototyp · Interview

„Ja, würde ich benutzen.“

Behavioral Prototype

Was Menschen wirklich tun

  • Gestartet
  • Abgebrochen
  • Wiedergekommen

  1. Aus der Fassade wird ein Behavioral Prototype

    Ein Behavioral Prototype ist funktionale Software für genau eine Hypothese. Echte Menschen können ihn in ihrem Alltag benutzen. Wir sehen, wer startet, wiederkommt, abbricht oder bezahlt. Er ist kein MVP und kein Produktionscode. Sobald die Frage beantwortet ist, löschen wir ihn. Die reinen Tool- und API-Kosten liegen heute oft bei rund 400 Euro. Dadurch können wir mehrere Varianten testen, bevor ein MVP entsteht.

    • Verhalten statt Absichtserklärungen: Du siehst, wer dreimal startet, wo abgebrochen wird, wer bezahlt
    • Echter Kontext statt Interviewraum
    • Rund 400 Euro statt Wochen Entwicklungszeit
    • Mehrere Varianten parallel, weil eine Variante nicht mehr das Budget frisst
    • Der Code ist Wegwerfware, die Verhaltensdaten sind es nicht

  2. Du musst dich nicht mehr auf eine Idee einengen

    Im klassischen Sprint wählt das Team am dritten Tag eine von mehreren Skizzen aus. Der Grund war ökonomisch: Es ließ sich nur ein Prototyp bauen. Heute können mehrere Richtungen parallel als kleine Prototypen entstehen. Erst das beobachtete Verhalten zeigt, welche trägt. Ideation bleibt. Die endgültige Auswahl vor dem Bauen fällt weg.

  3. Der Test verlässt den Interviewraum

    Solange der Prototyp eine Fassade war, musste er moderiert vorgelegt werden. Funktionale Software geht an echte Nutzer:innen im echten Kontext. Statt „würde ich benutzen“ siehst du, wer dreimal startet, wo abgebrochen wird und wer nach Tag fünf bezahlt.

  4. Weniger Workshop vor dem ersten MVP

    Mit 30 bis 40 Prozent Sicherheit meinen wir: Das Team sieht genug Hinweise, dass Problem, Zielgruppe und Nutzungshypothese plausibel sind. Für ein teures Entwicklungsprojekt wäre das zu wenig. Für einen MVP mit Gesamtkosten von 4.000 bis 7.000 Euro reicht es, um im Markt weiterzulernen. Ist die Richtung noch unschärfer, bauen wir zuerst einen Behavioral Prototype. Ist sie klarer, bringt ein weiterer Workshop meist weniger als echtes Verhalten.

  5. Der Engpass ist Zugang, nicht Bauen

    Wenn Bauen billig wird, wird die knappe Ressource die Aufmerksamkeit der Nutzer:innen. Die Frage ist nicht mehr „schaffen wir den Prototyp bis Donnerstag“, sondern „wen setzen wir am Freitag davor“.

Auf einen Blick

Element Klassischer Sprint Mit Vibe Coding
Was am vierten Tag entsteht Eine Fassade. Sieht echt aus, dahinter ist nichts Ein Behavioral Prototype: Software, die läuft und die Menschen wirklich benutzen
Was der Test misst Was fünf Testpersonen sagen, dass sie tun würden Was Menschen im Alltag tatsächlich tun
Wie viele Ideen in den Test gehen Eine. Die anderen sterben in der Abstimmung Mehrere parallel. Das beobachtete Verhalten zeigt, welche trägt
Wie sicher die Richtung vor dem MVP sein muss Rund 60 Prozent, sonst lohnt der Aufwand nicht 30 bis 40 Prozent reichen, weil ein Fehlversuch wenig kostet
Woran es hakt Am Bauen. Es dauert zu lange und kostet zu viel Am Zugang. Der Prototyp steht, aber wer benutzt ihn?

Was unverändert wichtig bleibt

Unverzichtbar bleibt die Frage am Anfang. Sie muss so klar sein, dass ein Test sie widerlegen kann. Schnelles Bauen macht diese Arbeit wichtiger: Ohne klare Frage entsteht nur schneller mehr Software. AI ersetzt auch das Gespräch nicht. Wer die Pause vor einer Antwort hört und nachfragt, erkennt Zusammenhänge, die in einem Transkript leicht verschwinden.

Lean Startup fordert seit Jahren: Teste billig, bevor du groß baust. In der Praxis wurde aus dem Experiment trotzdem oft ein Entwicklungsprojekt für fünfstellige Beträge. AI verändert die Grundidee nicht. Sie macht das Experiment endlich so günstig, wie es die Methode voraussetzt.

Das ist ein Zwischenstand, kein fertiges Modell. Wir arbeiten seit gut einem Jahr so und justieren mit jedem Projekt nach. Wo es bricht und wo es trägt, lernen wir gerade noch. Widerspruch ist ausdrücklich willkommen.

Eine Woche, konkret

Fünf Tage, ein Bruchteil der Leute.

Ein Anbieter für Leistungsdiagnostik wollte wissen, ob Sportler:innen ihre eigenen Messwerte überhaupt anschauen. Bis dahin gab es einen Laborbericht, geschrieben für Ärzt:innen. So sah die Woche aus, in der wir das geklärt haben.

  1. Tag 1Rechercheeine Person

    AI-gestützte Recherche durch Foren, App-Reviews und Produkte, die den Sprung von der Klinik zum Konsumenten geschafft haben. Am Abend liegen über 20 Hypothesen auf dem Tisch, keine davon geraten.

  2. Tag 2Interviewszwei Personen

    Fünf Gespräche mit möglichen Erstnutzer:innen. Wir prüfen, welche Hypothesen zu ihrem Alltag passen und warum. Fast hundert Aussagen und Beobachtungen werden dokumentiert. Daraus entsteht die Frage für den Prototyp.

  3. Tag 3Ideationsechs Personen, halber Tag

    Für die Ideation kommt unser Team mit den Fachleuten des Kunden zusammen. Aus Recherche und Interviews entsteht eine Richtung: Messdaten sollen wie eine verständliche Geschichte funktionieren, nicht wie ein Klinikbericht. Daraus formulieren wir eine Hypothese, die scheitern kann: Schauen Sportler:innen ihre Werte an, wenn wir sie als Geschichte statt als Tabelle zeigen?

  4. Tag 4Bauenzwei Personen

    Ein Behavioral Prototype. Funktionale Software zum Wegwerfen, schlank genug für den Umbau zwischen zwei Tests, funktional genug, um echtes Verhalten zu erzeugen. Kein MVP, kein Produkt.

  5. Tag 5Testzwei Personen

    Acht Marathonläufer:innen, je 90 Minuten. Erst die Spiroergometrie, dann der Prototyp am eigenen Ergebnis. Beobachtet wurde, was sie tun, nicht nur, was sie sagen.

Blasse Reihe: die sieben Personen, die im klassischen Sprint an jedem der fünf Tage im Raum sitzen. Die Zahl stammt aus „Sprint“ (Knapp, 2016), das Format empfiehlt sechs bis acht.

Der klassische Sprint bindet sieben Personen für fünf Tage: 35 Personentage. In unserem Beispiel kommen wir auf zehn. Das vollständige Team brauchen wir nur für einen halben Tag Ideation.

Das spart nicht nur Personentage. Acht Testpersonen nutzen den Prototyp mit ihren eigenen Messwerten. Zwischen den Terminen können wir ihn umbauen und die Änderung direkt im nächsten Test prüfen. So lernen wir während der Testreihe, nicht erst danach. Im klassischen Sprint wären mehrere Ideen schon vor dem Test durch Abstimmung ausgeschieden.

Belege

Zwei, die schon gelaufen sind.

Accenture: 14 ausgebildete Sprint-Moderator:innen in zwei Tagen → Kickbox-Programm: fünf Verlagsteams in zwölf Wochen →

Häufige Fragen

Design Sprints, kurz beantwortet

Was ist ein Design Sprint?
Ein Design Sprint ist ein strukturiertes Workshop-Format, das eine Produktfrage in wenigen Tagen von der Idee zum getesteten Prototyp bringt. Fünf Phasen, also Verstehen, Skizzieren, Entscheiden, Prototyp und Testen, ersetzen die übliche Abfolge aus Meetings, Abstimmungen und Konzeptrunden. Am Ende steht kein Beschluss, sondern eine Beobachtung: was Testpersonen mit dem Prototyp tatsächlich gemacht haben.
Wie lange dauert ein Design Sprint?
Das klassische Format dauert fünf Tage, eine Phase pro Tag. Kondensierte Varianten kommen mit zwei aufeinanderfolgenden Halbtagen à vier Stunden aus und liefern am Ende ebenfalls ein vollständiges Storyboard. Acht Stunden am Stück empfehlen wir nicht: die Konzentration hält nicht so lange, und der zweite Tag lebt von der Nacht dazwischen.
Wie viele Menschen gehören in einen Design Sprint?
Sechs bis acht Personen. Kleiner wird die Bandbreite der Skizzen zu schmal, größer werden die Übungen zäh und die Abstimmungen unscharf. Wichtiger als die Zahl ist die Besetzung: Es muss jemand dabei sein, der die Entscheidung am Ende auch treffen darf.
Was kostet ein Design Sprint Workshop?
Wir arbeiten ohne Listenpreis, weil Format, Gruppengröße und Vorbereitung den Aufwand bestimmen. Ein zweitägiges Moderationsformat und ein fünftägiger Sprint mit Rekrutierung von Testpersonen sind zwei verschiedene Dinge. Nach einem 30-minütigen Erstgespräch bekommst du ein Angebot mit klarem Scope und definiertem Ergebnis.
Was unterscheidet Design Sprint und Design Thinking?
Design Thinking ist ein Denkrahmen ohne festen Zeitplan, der Divergenz und Konvergenz beschreibt. Der Design Sprint ist ein konkreter Ablauf mit Uhr: feste Übungen, feste Reihenfolge, ein Prototyp und ein Test am Ende. Wer Orientierung sucht, greift zum Rahmen. Wer eine Entscheidung braucht, greift zum Sprint.
Wann ist ein Design Sprint der falsche Griff?
Wenn die Frage nicht am Konzept hängt, sondern am Verhalten. Der Prototyp im Sprint ist eine Fassade, die im Interview getestet wird, und die Antwort ist eine Absichtserklärung: was jemand sagt, dass er tun würde. Ob Menschen ein Produkt im Alltag wirklich benutzen, wiederkommen oder dafür bezahlen, zeigt erst funktionale Software im echten Kontext. Auch wenn die Entscheidung längst gefallen ist und nur noch Zustimmung gesucht wird, ist der Sprint das falsche Werkzeug.
Verändert AI den Design Sprint?
Ja. Vor allem das Prototyping verändert sich. Im klassischen Sprint entsteht am vierten Tag eine Fassade, weil funktionale Software früher nicht an einem Tag baubar war. Heute kann dort ein Behavioral Prototype entstehen. Recherche und Interviews schärfen weiterhin die Frage. Ideation bleibt, aber mehrere Richtungen können gebaut werden. Der Test findet mit funktionaler Software im Alltag statt, nicht nur als moderiertes Interview. Die fünf Aufgaben bleiben. Ihre Verteilung auf die Tage verändert sich.
Brauchen wir noch einen Sprint, wenn wir direkt bauen können?
Wenn die Frage bereits scharf ist: nein, dann baut direkt. Der Sprint verdient sich seinen Platz dort, wo die Frage noch unscharf ist, wo ein Team fünf Meinungen und keine formulierte Hypothese hat. Seine eigentliche Leistung war nie der Prototyp, sondern die formulierte Frage davor. Billiges Bauen macht das nicht überflüssig, es macht nur das Bauen ohne Frage gefährlicher: Du kannst jetzt sehr schnell sehr viel Falsches herstellen.
Bildet ihr auch interne Moderator:innen aus?
Ja. Statt für ein Team zu moderieren, lassen wir die Teilnehmenden selbst moderieren und geben Feedback nach jeder Übung. Für Accenture Interactive haben wir so in zwei Tagen 14 UX-Designer:innen, Projektmanager:innen und Product Owner zu Sprint-Moderator:innen ausgebildet.

Vertiefung

Texte aus der Praxis.

Zum Format

Zur Verschiebung

Nächster Schritt

Klär zuerst, ob ein Sprint die richtige Frage trifft.

Ein Erstgespräch dauert 30 Minuten. Danach wissen wir beide, ob dein Problem einen Sprint braucht, einen Behavioral Prototype oder keins von beidem.

Erstgespräch buchen Methode ansehen