Von Google lernen: So funktionieren Design-Sprints
Google Ventures Design Sprints. (Quelle: Youtube)
Bei der Entwicklung von Webseiten und Web-Anwendungen kann der Planungs- und Designprozess sehr viel Zeit in Anspruch nehmen. Eine gute Planung ist zwar ein wichtiger Faktor für die Entwicklung jeglicher Produkte – oft verstrickt man sich aber in kleinen Details, nur um dann festzustellen, dass das Endprodukt vom Benutzer nicht den eigenen Vorstellungen entsprechend angenommen wird.
Jake Knapp betreut zahlreiche der 150 Startups im Portfolio von Google Ventures. Aufgrund seiner Erfahrungen in der Zusammenarbeit mit verschiedenen Startups aus dem Ventures-Programm hat er einen Prozess mit „berechenbar guten Ergebnissen“ auf die Beine gestellt: den Design-Sprint.
Warum Design-Sprints?
Die Idee zu den Design-Sprints entstand durch die Erkenntnis, dass Brainstormings zwar oft viele gute Ideen hervorbrachten, aber durch die Gruppendynamik einige Probleme entstanden. Spätestens bei der Entscheidung über „gute“ und „schlechte“ Ideen wurden immer Kompromisse eingegangen, die dazu führten, dass einige gewagte Ideen es nicht in das finale Konzept schafften. Auch stellte Knapp fest, dass viele „brillante“ Ideen nicht aus einer Gruppe heraus kamen sondern von einzelnen Personen, die sich die nötige Zeit nehmen konnten um ihre Idee in Ruhe weiterzuverfolgen.
Auch Zeitdruck spielt laut Knapp eine gewisse Rolle. Ohne feste Deadlines tendiert man dazu, Dinge vor sich herzuschieben. Wenn ein fester Abgabetermin vor der Tür steht, arbeitet man jedoch konzentrierter und zielgerichteter.
Wie funktioniert’s?
Die fünf Schritte eines Product-Design-Sprints. (Quelle: Youtube)
Ein Design-Sprint ist ein fünftägiger Prozess mit dem Ziel, ein Produkt oder die Weiterentwicklung eines Produktes in kürzester Zeit, unter Zuhilfenahme von Team- und User-Input zu realisieren. Hierbei liegt der Fokus auf der Herausarbeitung eines visuellen Konzeptes für die Benutzerführung.
Der Sprint unterteilt sich in fünf Schritte, die in den fünf Tagen des Design-Sprints durchgeführt werden.
In einem Video fasst Jake Knapp den Vorgang kurz zusammen:
Der Ablauf eines Design-Sprints
Tag 1: Verstehen
Am ersten Tag gilt es, das Problem beziehungsweise die Aufgabenstellung für alle Beteiligten möglichst klar aufzuzeigen. Jeder Beteiligte muss das Geschäftsmodell des Unternehmens verstehen um für die nächsten Schritte gerüstet zu sein. Entwicklungen aus der Vergangenheit werden zur Sprache gebracht und analysiert, welche Neuerungen in letzter Zeit positive und welche negative Entwicklungen mit sich brachten. Man schaut sich Unternehmen mit ähnlichen Produkten an, die Lösungen für das vorab definierte Ziel anbieten, um mögliche Anknüpfungspunkte zu finden.
Tag 2: Lösungsansätze finden
Der zweite Tag wird der Findung von Lösungen gewidmet. Dabei gilt es viele verschiedene Ansätze für die Lösung der am ersten Tag festgestellten Probleme zu finden. In dieser Phase kann jeder seine Ideen zu Papier bringen. Anders als beim Brainstorming arbeitet man hier ungestört und muss seine Ideen nicht zunächst in einer Gruppe durchsetzen. Der Prozess beschränkt sich nicht auf Designer: Jeder vom Designer bis zum CEO soll seinen Input beisteuern können.
Tag 3: Entscheiden
Am dritten Tag müssen die besten Ideen ermittelt und eine User-Story herausgearbeitet werden. Hierfür beschreibt Knapp einen Auswahlprozess mit Hilfe von Stickern. Jeder kann mit einem Sticker auf den Entwürfen der Kollegen gute Ideen markieren. Durch die so entstehenden „Heatmaps“ kristallisieren sich schnell die besten Ideen heraus. Diese können dann im Team kombiniert und zu ersten Mockups und einer User-Story verarbeitet werden.
Tag 4: Prototypen
Am vierten Tag entstehen die Prototypen des Produktes, die später Benutzern vorgeführt werden können. Die Prototypen müssen für Externe benutzbar sein und sich halbwegs echt anfühlen, um später ein möglichst realistisches Feedback erhalten zu können. In seinem Blogbeitrag empfiehlt Knapp hierfür Keynote.
Tag 5: Überprüfen
Am fünften Tag wird der Prototyp Testern vorgeführt um herauszufinden, welche der Ideen tatsächlich funktionieren und welche nicht. Hierfür werden die am vierten Tag entwickelten Prototypen „echten“ Benutzern vorgelegt. Also Menschen außerhalb des Unternehmens, die im besten Fall bisher keine Erfahrungen mit dem jeweiligen Produkt sammeln konnten.
Durch gezielte Fragestellung und das User-Feedback können so Ideen bestätigt oder verbesserungswürdige Punkte im Konzept aufgedeckt werden.
Fazit
Design-Sprints vereinen Zeitdruck, Teamarbeit und User-Feedback, lassen aber durch das Wegfallen des klassischen Brainstormings bei der Ideen-Entwicklung auch Platz für individuelle Herangehensweisen. Somit ist das fünftägige Design-Sprint-Konzept eine gute Möglichkeit, um in kleinen Gruppen schnelle und messbare Ergebnisse zu erzielen.
Detaillierte Beschreibungen zu jedem einzelnen Tag des Design-Sprints gibt es auf dem Google-Ventures-Blog.
Was denkst du über das Design-Sprint-Konzept? Welche Techniken funktionieren in deinem Team am besten? Sag’s uns in einem Kommentar.
Da frage ich mich: Welcher Kunde erwartet denn tatsächlich, bereits nach fünf Tagen einen ersten Prototyp vorgelegt zu bekommen bzw. wer bin ich als Dienstleistungsanbieter, mich selber unter diesen Zeitdruck zu stellen?!
Da hast du was angesprochen!
Genau deswegen habe ich den Online Design Sprint ins Leben gerufen – hier hat man bis zu 30 Tage Zeit:
http://onlinedesignsprint.com/
Ich denke die Zeit ist nicht wichtig. Entscheidend sind die Phasen!
Es sind 5 Leute, sie haben 5 Tage und müssen lediglich EIN Feature prototypen – das geht doch hoffentlich :)
Ich denke auch bei größeren Projekten muss das einfach reichen – es ist, wie schon gesagt, nur eine Variante des Brainstormings und soll nur eine grobe Richtung angeben – ganz im Sinne von Sprints (release early, release often).
Wenn es ein gutes Produkt ist, dann erwartet der Kunde nicht nur am 5., sondern bereits sofort eine passende Lösung und zahlt auch für einen Prototyp! Als Dienstleister kann man mit solchen Ansätzen nicht nur bessere Produkte entwerfen, sondern auch viel Zeit, Geld und Nerven sparen. Bei der Moderation bzw. Facilitation solcher Design Sprints unterstützen wir gern: http://www.mak3it.de/innovation-sprint/
Wenn der Kunde bereits ein gutes Produkt hat, wird er „roughe“, vermeintliche Lösungen vermeiden, die aus dem Ärmel geschüttelt wurden. Er wird strukturierte, dokumentierte und damit nachvollziehbare Design Entscheidungen verlangen.
Andere Kunden/Startups werden bis dahin leider die Erfahrung mit Agenturen machen, deren Erzeugnisse nicht auf der Kontextanalyse der Anwender beruhen, sondern auf vermeintliche Expertise (Stichwort „authority bias“) gepaart mit eben solchen Design-Methodiken.
Leider ist der Begriff Design nie geschützt worden, weshalb ihn jetzt jeder bemüht, wenn er eine positive Aussage braucht.
Der Anspruch, in 5 Tagen eine Arbeit hochwertig und fehlerfrei gelöst zu haben, zeugt von tiefem Unverständnis der Materie. Das kann nur von einem Folieningenieur aus der Betriebswirtschaft kommen. Ein Designer nimmt so einen Auftrag gar nicht an, weil er seinen Kollegen, dem Nutzer und letztlich auch dem Auftraggeber nur schadet. Ein Programmierer sollte sich das auch überlegen, auch wenn die gewöhnlich anonym arbeiten. Viel Freude an der Zettelwand!
Es wird keine hochwertige und fehlerfreie Arbeit verlangt, sondern ein Prototyp, auf dem weiter iteriert wird. Durch die extrem verdichtete Organisationsform kann man sehr fokussiert arbeiten und sich wirklich fünf Tage an einem Produkt austoben. Das ist inspirierend und erlaubt mehr kreative Investition als ein wöchentlicher Slot von zwei Stunden zwischen Jour Fixe A und Kundenprojekt B.
Das klingt so ein bischen wie die Meinung von VV, oben aus 2014, von dem wir ausgegangen waren. Was ich suche ist einfach ein Hauch von Qualität, durchgängige Logik, einheitliche Nomenklatur und wenns geht bitte keine Menues in einer ganz anderen Sprache, wie auf dieser Seite.
Wenn die „echten“ Anwender erst am letzten und nicht am ersten oder zweiten Tag involviert werden besteht die Gefahr, dass die Designer, CEOs, etc. wesentliche Probleme nicht erkennen.
Statt als Ressource valider Anforderungen zu dienen, werden die tatsächlichen Anwender verwendet, um Annahmen anderer zu validieren.