Über unsMediaKontaktImpressum
Heiko Stapf 14. November 2017

Design Sprints – Design Thinking anwenden

Der Vorteil an Design Sprints ist, dass sie einen Design Thinking-ähnlichen Prozess in kompakten fünf Tagen durchlaufen. © JKstock / Fotolia.com
© JKstock / Fotolia.com

Wer über Innovationen und Kundenzentrierung nachdenkt, kommt am Design Thinking-Ansatz nicht vorbei. In vielen Kurzworkshops habe ich dieses Thema vorgestellt, die Teilnehmer waren begeistert, der Transfer in den Arbeitsalltag fand jedoch selten statt. Im Rahmen einer Product Owner-Anstellung bin ich 2015 auf die Google Design Sprints gestoßen. Das von Google Ventures entwickelte Konzept liefert ein hervorragendes Rezept, Design Thinking in der Organisation einzusetzen.

Design Thinking – macht das Sinn?

Design Thinking wird maßgeblich von der Innovations-Agentur IDEO, der "d.school" an der Stanford-Universität und dem Hasso-Plattner-Institut für Design (HPI) vorangetrieben. In seinem Buch "Change by Design"  beschreibt Tim Brown den Design Thinking-Ansatz so [1]:

"Wir benötigen einen mächtigen, effektiven und allgemein zugänglichen Innovationsansatz, der in alle Bereiche der Wirtschaft und Gesellschaft integriert werden kann und Einzelnen und Teams erlaubt, bahnbrechende Ideen zu entwickeln und sie wirkungsvoll zu implementieren. Design Thinking liefert diesen Ansatz.“

Dass dieses Ziel sinnvoll und erfolgversprechend ist, zeigt beispielsweise der vom Design Management Institute entwickelte Design Value Index (DVI). Dieser Index vergleicht die Börsenwerte von Unternehmen; die Design-Kriterien des Design Management Institutes folgen mit dem S&P 500 [2]. Das Ergebnis ist eindeutig: Firmen aus dem Design Value Index entwickeln sich über 200 Prozent besser, als der S&P 500 [3].

Design Thinking – eine Kurzeinführung

Abb.1: Balance aus Kundenwunsch, Rentabilität und Realisierbarkeit. © Heiko Stapf
Abb.1: Balance aus Kundenwunsch, Rentabilität und Realisierbarkeit. © Heiko Stapf

Design Thinking sucht die Balance aus Kundenwunsch (Desirability), Rentabilität (Viability) und Realisierbarkeit (Feasibility). In vielen IT-Projekten ist dieses Gleichgewicht stark in Richtung der Realisierbarkeit und technischen Machbarkeit verschoben. Eine spannende technische Herausforderung stellt die Frage nach den Kundenwünschen oder der Rentabilität schnell in den Hintergrund. Dies führt zu teuer entwickelten, aber ungenutzten Features. Aus meiner Sicht hat Thorsten Dirks (Telefonica Deutschland AG) das Problem im Umfeld der Digitalisierung sehr gut auf den Punkt gebracht:

"Wenn Sie einen Scheißprozess digitalisieren, dann haben Sie einen scheiß digitalen Prozess."

Um erfolgreiche Innovationen zu ermöglichen, propagiert Design Thinking grundsätzliche Prinzipien, eine modellhafte Beschreibung des Design Prozesses und viele Methoden und Tools [4], um diese Prinzipien und das Modell erfolgreich umzusetzen.

Die Prinzipien:

  • Fokussiere Dich auf den Menschen
  • Entwickle eine Neigung zum Handeln
  • Erzähle nicht von Deinen Ideen, sondern zeige sie
  • Experimentiere
  • Achte auf den Prozess
  • Arbeite "radikal" (im Sinne von sehr intensiv) mit anderen zusammen
  • Entwickle Klarheit

Außerdem beschreibt Design Thinking den Design-Prozess mit folgenden Schritten:

  • Empathie: verstehe die Anwender, Kunden deines Produktes, ihre Situation, ihre Bedürfnisse und Wünsche
  • Definiere: stelle Klarheit bezüglich der zu lösenden Aufgabe her.
  • Entwerfe (Ideate): erzeuge viele Ideen, die die Aufgabe lösen könnten.
  • Prototype: erstelle Prototypen die Deine Idee erleb- und greifbar machen.
  • Test: Teste Deine Idee mit Deinen Kunden und Anwendern.

In anderen Definitionen werden zum Teil 6 Prozessschritte verwendet [5].

Probleme in der Anwendung

Von den Ideen und Möglichkeiten überzeugt, wollte ich diesen Ansatz einsetzen. Trotz diverser Vorträge und Workshops mit begeisterten Teilnehmern zündete das Thema nicht und ließ sich nicht platzieren. Hierfür gibt es nach meiner Beobachtung folgende Gründe.

  1. "Wir wissen, was unsere Kunden wollen" ist eine Haltung, die ich oft angetroffen habe.
  2. Die Organisationsstruktur vieler Firmen erlaubt die geforderte "radikale Zusammenarbeit" nicht. Organisationen sind häufig nach Funktionen (Produkt Management, Entwicklung, Design …) aufgeteilt. Innovationen verlangen nach crossfunktionalen, auf ein gemeinsames Produkt ausgerichteten Teams [6]. 
    "Wow… Klasse Idee! Als ich aber am nächsten Tag überlegt habe, wen ich alles um Erlaubnis für so ein Team fragen müsste, hat mich schnell der Mut verlassen." (Zitat eines Workshop Teilnehmers)
  3. Konflikte zwischen den Disziplinen. Aufgrund der lang eingeübten Aufteilung in funktionale Gruppen entwickeln sich unterschiedliche Ziele und Kulturen. Oftmals existieren Misstrauen und diverse Animositäten zwischen den verschiedenen Abteilungen, die eine konstruktive Zusammenarbeit erschweren.
  4. Fehlender Fokus auf die Innovation. Aus Auslastungsgründen arbeiten die funktionalen Einheiten an vielen verschiedenen Themen gleichzeitig. Der gemeinsame Fokus auf ein neues Produkt fehlt bzw. geht im Tagesgeschäft unter.
  5. Reden statt Handeln. Statt "Bias toward action" leiden Design Thinking-Initiativen unter langatmigen Genehmigungs- oder Abstimmungsprozessen. Bildlich gesprochen versickern Initiativen zwischen den vielen Übergabeschnittstellen der funktional aufgestellten Organisation.
IT-Tage 2017 - Agile Entwicklung

Design Sprints – die Entdeckung

2015 bin ich gemeinsam mit meinen Product Owner-Kollegen in einem größeren Kundenprojekt auf die Design Sprints von Google Ventures aufmerksam geworden [7]. Die etwas später in dem sehr guten Buch "Sprint" von Jake Knapp beschrieben wurden [8]. Auch in diesem Projekt hatten wir mit den beschrieben Problemen bei der Einführung von Design Thinking zu kämpfen. Mit den Design Sprints sahen wir eine Möglichkeit für ein spannendes Experiment. Der Vorteil dieser Methode war aus unserer Sicht, dass sie einen Design Thinking-ähnlichen Prozess in kompakten fünf Tagen durchläuft.

Wir waren uns sehr schnell einig, dass wir dieses Konzept ausprobieren wollten. Aufgrund des überschaubaren und klar definierten Rahmens gelang es uns, die notwendigen Beteiligten aus den verschiedenen Disziplinen (Produkt Management, User Experience Designer, Entwickler) für die fünf Tage zu gewinnen. Es gibt ähnliche Konzepte und Ansätze im Design Thinking, aber der Fokus auf die 5 Tage und natürlich der Name "Google Ventures" setzten neue Kräfte frei.

Das Konzept

Abb.3: Die fünf Phasen des Design Sprint. © Heiko Stapf
Abb.3: Die fünf Phasen des Design Sprint. © Heiko Stapf

Ein Design Sprint besteht aus fünf Phasen, aufgeteilt auf fünf aufeinanderfolgende Tage.

Tag 1: Unpack – Verstehe

An diesem Tag klärt das Team das gemeinsame Ziel des Design Sprints. Die Schaffung eines gemeinsamen Fokusses und Verständnisses für die Aufgabe steht im Mittelpunkt. Fünf Tage vergehen schnell und ein klar definiertes Ziel ist unabdingbar für den Erfolg des Sprints.

An Tag 1 werden z. B. folgende Methoden eingesetzt:

  • "Wie können wir…"-Fragen
  • Hypothesen-Templates
    Wir vermuten …, wir testen dies indem wir…, wir sehen die Hypothese bestätigt, wenn…
  • Story Mapping [9]
  • SMARTe Ziele

Google Design Sprints schlägt vor, an diesem Tag weitere Experten aus der Organisation hinzuzuziehen, die beim gemeinsamen Verständnis des Themas unterstützen können.

Der Unpack-Tag deckt Teile der Empathie-Phase und die Definiere-Phase aus Design Thinking ab. Meine Erfahrungen aus mehreren Design Sprints haben allerdings deutlich gemacht, dass der Unpack-Tag die Empathie-Phase nicht vollständig abbilden kann. Aus diesem Grund betreiben wir heute im Vorfeld eines Design Sprints User Research mit Kunden-Beobachtung und -Interviews. Im Rahmen eines Design Sprints für eine Drogeriekette führte dies z. B. dazu, dass alle Teammitglieder einen Tag in der Filiale mitgearbeitet haben, um die Situation der Mitarbeiter besser zu verstehen.

Tag 2: Sketch – Entwerfe

Am zweiten Tag geht es darum, möglichst viele unterschiedliche Ideen zu entwickeln, wie das Problem des Anwenders gelöst werden kann. Häufig schicke ich die Teilnehmer hierfür zunächst auf eine "Schnitzeljagd" ins Internet. Dort sollen sie nach Ideen und bereits vorhandenen Lösungen suchen und diese kurz präsentieren. Über die Crazy 8-Methode [10] und eine Vielzahl anderer Kreativtechniken wird dann der Lösungsraum weit geöffnet.

Im Laufe des Tages erarbeiten die Teilnehmer eine Art Werbeplakat für ihre Lösungsidee. Eine spannende Erkenntnis hierbei ist, dass es sehr sinnvoll ist, die Teilnehmer über weite Strecken "allein" an ihren eigenen Ideen arbeiten zu lassen. Dies beugt dem "Group Thinking-Effekt" vor, d. h. dass das Team sich zu früh auf eine Lösung einigt.

Der zweite Tag entspricht der Ideate-Phase im Design Thinking.

Tag 3: Decide – Entscheide

Am dritten Tag entwickeln wir aus den vielen Ideen des zweiten Tages eine gemeinsame Lösung. Zunächst erstellen wir dafür eine sogenannte Heatmap. Dafür kennzeichnen die Teilnehmer interessante Ideen auf den Werbeplakaten des Vortages. Dies geschieht mit Klebepunkten. Im Gegensatz zu Abstimmungsverfahren sind hier die Punkte nicht begrenzt. Dadurch entstehen gut sichtbare Punktewolken rund um die spannenden Ideen.

Gleichzeitig wird bei der Vorstellung der Ideen nach gegensätzlichen Konzepten gesucht. Diese können im Kundentest gegeneinander getestet werden. Die Frage "Gefällt Ihnen Variante A oder B?" bzw. ein Test zweier Varianten liefert stärkere Erkenntnisse für die weitere Entwicklung als "Wie gefällt Ihnen A?" bzw. ein Test ohne den Vergleich mehrerer Varianten.

Aus diesen Ideen und Varianten erarbeitet das Team ein Storyboard für den Test am Freitag. Dies erfordert, dass viele schnelle Entscheidungen getroffen werden. Zur Beschleunigung der Entscheidungsfindung führen die Design Sprints den sogenannten "Decider" ein. Dies ist eine Person, die zwar angewiesen ist, auf die Vorschläge und Ideen der anderen Teilnehmer einzugehen, im Zweifelsfall aber dazu ermächtigt ist, Entscheidungen zu treffen. Angesichts der kurzen Zeitspanne habe ich diese Rolle immer als sehr nützlich empfunden – auch wenn er oder sie sich gegen meine Idee entschieden hat.

Eine weitere große Hilfe bei der Entscheidungsfindung ist die Fokussierung auf den Testtag am Freitag und auf das Sprintziel. Die einfache Frage "Was wollen und können wir am Freitag testen?" fängt allzu lange Diskussionen schnell wieder ein.

Der dritte Tag findet sich in der Define-Phase im Design Thinking wieder.

Tag 4: Prototype – Fake it!

Wir bauen einen Prototypen, mit dem wir die Ideen und Varianten aus den ersten Tagen testen können. Neben einfachen Click Through Dummies kommen Rollenspiel-Techniken, Papier-Prototypen, Interviews und viele andere Methoden zum Einsatz. Auch hier ist der begrenzte Zeitrahmen durchaus von Vorteil – verhindert er doch allzu ausufernde Konstrukte und fokussiert immer wieder auf die wirklich wichtigen Fragen des Sprints. In dieser Phase ist es wichtig, dass erfahrene Prototypen-Entwickler im Team sind, die schnell und fokussiert minimalistische Prototypen umsetzen können.


In einem meiner ersten Design Sprints ist der vierte Tag stark ausgeufert, da versucht wurde, einen Prototyp zu bauen, der bereits eine komplette Bedienungsumgebung für den Nutzer schafft. Dies ist aber für die Beantwortung vieler Fragen nicht notwendig. Das Ziel sind sehr eingeschränkte und auf die Beantwortung der Sprintfragen fokussierte Prototypen und Tests. Außerdem ist es sehr wichtig, an diesem Tag die Tests anhand eines Skriptes zu planen und bereits im Team durchzuspielen und zu testen, damit der Testtag reibungslos abläuft.

Der vierte Tag ist identisch mit der Prototype-Phase im Design Thinking.

Tag 5: Test – Testen mit Anwendern

Am fünften Tag werden die Sprintfragen und Hypothesen anhand der entwickelten Prototypen mit Anwendern getestet. Hierzu bin ich teilweise zu Agenturen gegangen, die auf User-Tests spezialisiert sind, oder im Falle des Drogeriemarktes direkt zu den Filialen. Da es sich um fünf über die gesamte Stadt verteilte Filialen handelte, hat das Wort Sprint in diesem Projekt wieder seine ursprüngliche Bedeutung bekommen.

Dieser Test erfordert erfahrungsgemäß etwas Vorbereitung – sei es, entsprechende Agenturen zu beauftragen oder z. B. die Abstimmung mit den Filialen. Daher macht es Sinn, diese Organisation bereits im Vorfeld eines Design Sprints durchzuführen.

Die Tests bestehen aus einer klaren Aufgabenstellung für den Benutzer. Beobachter oder eventuell Kameras zeichnen die Ereignisse auf. Häufig komplettieren wir den Test durch ein nachgelagertes kurzes Interview.

Der fünfte Tag entspricht der Test-Phase aus dem Design Thinking.

Voraussetzungen

Aufgabenstellung

Zunächst braucht es ein grobes Ziel für den Design Sprint. Aus den verschiedenen Design Sprints konnte ich drei verschiedene Aufgabenebenen identifizieren:

  • Wofür-Ebene: Was sind die grundsätzlichen Bedürfnisse/Wünsche der Kunden und wie können erste grobe Lösungsideen aussehen?
  • Wie-Ebene: Das Problem ist grundsätzlich bekannt. Mit welchen Prinzipien und grundsätzlichen Vorgehensweisen kann es gelöst werden?
  • Was-Ebene: Sowohl Problem als auch grundsätzliche Lösungsideen sind bekannt. Konkrete Ideen und Lösungen werden auf Kundentauglichkeit getestet.

Die Anwendungsbereiche sind sehr vielfältig. Wir haben z. B. die Entwicklung von Smart Home-Produkten begleitet oder die Fragestellung, mit welchen Mitteln wir die Mitarbeiter bei der Beratung am Point of Sale  einer Drogeriekette unterstützen können.

Teamzusammenstellung

Nachdem die grobe Aufgabenstellung geklärt ist, wird ein geeignetes Team zusammengestellt. Bei Google Ventures wurden die Design Sprints häufig im Startup-Umfeld eingesetzt, d. h. ich gehe davon aus, dass dort bereits cross-funktionale Teams vorhanden waren und dieser Schritt nicht notwendig war.
Wie erwähnt hat sich in meiner Arbeit die Organisationsstruktur als größter Stolperstein für die Umsetzung von Design Thinking erwiesen. Dies zeigt sich z. B. darin, dass für alle Design Sprints, die ich bisher begleiten durfte, zunächst ein neues Team zusammengestellt wurde. Geeignet bedeutet neben "hat Zeit" natürlich die cross-funktionale Besetzung des Teams – vorhandene Teams erfüllten diesen Anspruch nicht.

In unserem ersten Design Sprint waren dies zunächst Teilnehmer aus dem Produkt Management, User Experience-Designer und interessierte Entwickler (normalerweise getrennte Organisationseinheiten). Uns wurde schnell klar, dass wir eine wichtige Gruppe vergessen hatten: die Anwender. Zwar hatten wir für den Testtag bei einer Agentur Kunden angefordert, uns wurde aber schnell bewusst, dass wir diese Kunden bereits während des Sprints benötigen. Da es sich um ein Consumer-Produkt handelte, konnten wir zum Glück spontan auf "unbeteiligte" Mitarbeiter in der Organisation zugreifen.

In weiteren Design Sprints für einen Drogeriemarkt bestand das Team z. B. aus Filialleitern, Filialmitarbeitern, Weiterbildungsspezialisten, User Experience-Designern und Entwicklern. Und immer dabei und unverzichtbar: ein guter Moderator, der in der Lage ist, den Prozess mit hoher Moderationskompetenz und einer Vielfalt an Methoden aus Moderation, Mediation und Design Thinking zu begleiten.

Ort

Ein großer und für die 5 Tage ausschließlich für den Design Sprint reservierter Raum mit großer Wand- oder Stellfläche (für Moderationswände oder große Kapa-Platten) ist eine weitere Voraussetzung für einen erfolgreichen Design Sprint.

Leider durfte ich Design Sprints erleben, bei denen wir mehrmals umziehen mussten. Da sämtliche Arbeitsergebnisse im Raum sichtbar an den Wänden visualisiert werden, sind solche Umzüge zeitlich sehr aufwändig und der räumliche Bezug zu den Ergebnissen geht verloren.

Fazit

Abb.3: Heatmap. © Heiko Stapf
Abb.3: Heatmap. © Heiko Stapf

Mit den Design Sprints ist es uns gelungen, den Design Thinking-Ansatz in Organisationen zumindest zeitweise einzusetzen. Unsere Kunden und Auftraggeber waren im positiven Sinne überwältigt von der Menge und Qualität der gewonnenen Erkenntnisse. Annahmen und Bauchgefühle wurden überprüft und der direkte Kontakt zum Kunden liefert viele spannende und unerwartete Erkenntnisse. Damit konnte erfolgreich der "Wir wissen was unsere Kunden wollen"-Haltung ein "...und wir können noch sehr viel lernen" hinzugefügt werden.

Kritisch sehe ich wie bereits erwähnt den Unpack-Tag. Hier habe ich gelernt, dass die wichtige Empathie-Phase aus Design Thinking durch zusätzlichen User Research unterstützt werden muss.

Die komprimierte cross-funktionale Arbeitsform überzeugt. Sehr eindrucksvoll hat das ein Manager ausgedrückt, als er erst am dritten Tag zu einem Design Sprint hinzukam: "Wenn ich gewusst hätte, dass hier so viel erarbeitet und entschieden wird, dann wäre ich lieber früher gekommen".

Viele Organisationen sind es nicht mehr gewöhnt, dass innerhalb so kurzer Zeit derart viele Erkenntnisse gesammelt und Entscheidungen getroffen werden. Auch bei den Mitarbeitern kamen die Design Sprints gut an: "Ich will gar nicht mehr anders arbeiten". Die im Raum sichtbaren Ergebnisse zeigen den Mitarbeitern, dass sie etwas bewegen können.

Die kompakte Durchführung innerhalb von fünf aufeinanderfolgenden Tagen ist extrem wichtig für den Erfolg des Design Sprints. Bei einem Design Sprint hat der Kunde beschlossen, den Testtag erst deutlich später zu veranstalten – mir ist nicht bekannt, dass dieser inzwischen stattgefunden hat.

Die Moderation der Design Sprints ist trotz der sehr guten Beschreibung sehr anspruchsvoll und erfordert erfahrene Moderatoren mit großer Methodenvielfalt. Auch erfahrene Teilnehmer (z. B. Entwickler mir Prototypen-Erfahrung oder UX-Designer) erhöhen die Ergebnisqualität der Design Sprints.

Quellen
  1. T. Brown, 2009: Change By Design
  2. Wikipedia: S&P 500
  3. Design Index vs. S&P 500
  4. Design Thinking-Materialien
  5. Informatik Aktuell – Patrick Lobacker: Innovationstreiber Design Thinking
  6. The New Product Development Game
  7. Google Ventures: Design Sprints
  8. J. Knapp, J. Zeratsky, B. Kowitz, 2016: Sprint: Wie man in nur fünf Tagen neue Ideen testet und Probleme löst
  9. J. Patton, 2014: User Story Mapping
  10. Crazy 8-Methode: Crazy 8 – Lass doch den Programmierer konzipieren
nach Oben
Autor

Heiko Stapf

Heiko Stapf ist Certified Scrum Trainer. Sein besonderes Interesse gilt der Entwicklung innovativer Produkte und Dienstleistungen und der Rolle des Product Owners in Scrum.
>> Weiterlesen
botMessage_toctoc_comments_929