Ansatz & Methode
Ein Design Sprint ist ein stark zeitlich begrenzter Prozess, in dem ein interdisziplinäres Team eine wichtige Herausforderung fokussiert, Lösungen entwickelt, einen realistischen Prototyp baut und mit echten Nutzerinnen oder Nutzern testet.
Kurz gesagt
Ein Design Sprint ist ein zeitlich stark begrenzter Innovationsprozess, der von Jake Knapp bei Google entwickelt und später bei Google Ventures weiterentwickelt wurde. Ein kleines interdisziplinäres Team fokussiert eine wichtige Herausforderung, entwickelt und bewertet Lösungsansätze, baut einen realistischen Prototyp und testet ihn mit echten Nutzerinnen oder Nutzern. Ziel ist schnelles Lernen vor einer größeren Investition in Umsetzung.
Weitere Bezeichnungen: GV Design Sprint · Google Design Sprint · Sprint-Methode
Diese beiden Listen beantworten die häufigste Frage zuerst: Wofür ist der Ansatz gedacht, und wann ist er die falsche Wahl? Alles Weitere auf dieser Seite vertieft genau diese Entscheidung.
Bei neuen Produkten, Services oder internen Lösungen können Wochen in Meetings und Konzeptpapieren vergehen. Ein Design Sprint erzwingt eine kurze gemeinsame Phase, in der das Team zu einer testbaren Darstellung der wichtigsten Annahmen kommt.
Vollständige Umsetzung ist teuer. Wenn erst danach deutlich wird, dass Menschen eine Lösung nicht verstehen oder brauchen, ist viel Aufwand verloren. Der Sprint versucht, kritische Annahmen mit einem realistischen, aber bewusst begrenzten Prototyp früher zu prüfen.
Ein interdisziplinäres Team kann sich verbal auf dieselben Ziele einigen und trotzdem verschiedene Vorstellungen davon haben, was konkret entstehen soll. Skizzen, Entscheidungen und ein gemeinsamer Prototyp machen diese Unterschiede früh sichtbar.
Der Sprint schützt mehrere Tage für eine klar definierte Herausforderung. Die kurze Taktung reduziert offene Diskussionen ohne Entscheidung und zwingt das Team, mit unvollständiger Information bewusst voranzugehen.
Lösungsideen werden zunächst parallel und häufig still entwickelt. Dadurch erhält das Team mehr als eine Ausgangsidee und reduziert den Einfluss der lautesten Stimme in einer frühen Brainstorming-Diskussion.
Design Sprints sehen eine Person oder Rolle vor, die bei wichtigen Richtungsentscheidungen Verantwortung übernimmt. Beteiligung und Entscheidung werden dadurch nicht verwechselt.
Der Prototyp muss realistisch genug sein, damit Testpersonen sinnvoll reagieren können, aber nicht vollständig funktionieren. Gebaut wird nur, was nötig ist, um zentrale Fragen zu beantworten.
Am Ende wird der Prototyp mit Menschen getestet, die zur Zielgruppe passen. Das Team beobachtet Muster in ihren Reaktionen und gewinnt dadurch Evidenz dafür, welche Annahmen weiterverfolgt, verändert oder verworfen werden sollten.
Das Team klärt das langfristige Ziel, sammelt Risiken und Fragen, erstellt eine vereinfachte Karte des Problems und entscheidet, welcher Teil innerhalb des Sprints untersucht werden soll.
Nach Inspiration durch vorhandene Beispiele entwickelt jedes Teammitglied eigene Lösungsansätze. Die Ideen werden konkret genug visualisiert, dass sie am nächsten Tag miteinander verglichen werden können.
Das Team bewertet die Vorschläge und entscheidet, welche Richtung getestet wird. Anschließend wird ein Storyboard erstellt, das festlegt, welche Erfahrung der Prototyp zeigen muss.
Das Team erstellt eine Fassade der späteren Lösung, die für einen Nutzertest glaubwürdig genug ist. Nicht benötigte Funktionen, Infrastruktur und Randfälle bleiben bewusst außerhalb des Prototyps.
Mehrere Einzeltests liefern Beobachtungen dazu, wie Menschen den Prototyp verstehen und nutzen. Das Team sucht nach wiederkehrenden Mustern und entscheidet anschließend, was gelernt wurde und welcher nächste Schritt sinnvoll ist.
Prüfe, ob das Thema wichtig, unsicher und innerhalb weniger Tage prototypisierbar ist. Ein Sprint sollte eine riskante Annahme verkleinern, nicht die gesamte Unternehmensstrategie in einer Woche lösen.
Stelle eine kleine interdisziplinäre Gruppe zusammen, benenne die Entscheidungsrolle und rekrutiere passende Testpersonen frühzeitig. Ohne diese Vorbereitung verliert der Sprint leicht seinen zeitlichen Vorteil.
Ein Sprint funktioniert nur eingeschränkt, wenn Beteiligte ständig in andere Meetings wechseln. Reserviere die Arbeitsblöcke und definiere klare Regeln für Geräte, Erreichbarkeit und Entscheidungen.
Beobachte, welche Muster sich über mehrere Gespräche zeigen. Ziel ist nicht, Zustimmung zum Konzept zu bekommen, sondern Annahmen zu prüfen und überraschende Reaktionen ernst zu nehmen.
Entscheide auf Basis der Tests, ob weiter recherchiert, erneut prototypisiert, verworfen oder in Entwicklung überführt wird. Zwischen Sprint-Prototyp und produktionsreifer Lösung liegt normalerweise weitere Arbeit.
Der Design Sprint greift Denkweisen aus Design Thinking, Nutzerforschung, Prototyping und Entscheidungsarbeit auf, komprimiert sie aber in einen stark strukturierten Zeitraum. Er ist damit kein Synonym für Design Thinking. Design Thinking kann über viele Iterationen und längere Forschungsphasen laufen; ein Design Sprint versucht bewusst, eine zentrale Unsicherheit in wenigen Tagen testbar zu machen.[1]
Ebenso ist ein Design Sprint kein Software-Development-Sprint. Das typische Ergebnis ist ein getesteter Prototyp und neues Wissen, nicht ein produktionsreifes Feature. Auch die offizielle Sprint-Community beschreibt den Prozess als Mittel, vor der Umsetzung Vertrauen in eine Lösungsrichtung aufzubauen.[2]
Ein Design Sprint ist keine New-Work-Methode im engen Sinn. Er kann jedoch zu einer lernorientierten Arbeitsweise passen, weil interdisziplinäre Teams fokussiert zusammenarbeiten, Entscheidungen sichtbar machen und frühes Feedback höher gewichten als lange interne Planung. Für Organisationsentwicklung ist der Ansatz vor allem dann relevant, wenn ein konkreter Service, Prozess oder eine neue Arbeitserfahrung prototypisiert werden kann. Fragen von Führung, Macht oder Organisationsstruktur werden durch einen Sprint nicht automatisch beantwortet.
Die Zuordnung stammt aus den strukturierten Methodenangaben der Profile und den ausgewiesenen Quellen.
Bild: cohive.works
Berlin, Deutschland
Transformation coach, consultant, and facilitator for leadership, innovation, and organizational development
CoHive
Martin Backes ist als Transformationscoach, Berater und Facilitator für Führung, Innovation und Organisationsentwicklung tätig. Er arbeitet mit CoHive in Berlin und bringt über 20 Jahre Erfahrung in Design, Führung, Innovation und Organisationsentwicklung mit.
Die Inhalte dieser Seite wurden eigenständig verfasst und anhand der folgenden öffentlichen Quellen geprüft.
Offizielle Website
Google Design
Quelle öffnenOffizielle Website
The Sprint Book / Jake Knapp and John Zeratsky
Quelle öffnenOffizielle Website
The Sprint Book / Jake Knapp
Quelle öffnenProfil
Jake Knapp
Quelle öffnenVergleiche Profile, die diesen Ansatz einsetzen – nach Rolle, Sprache und Zusammenarbeit.
Profil zum Ansatz ansehen