Was ist Design Thinking? Der Ansatz und seine 5 Phasen

Kurz gesagt

Design Thinking ist eine Arbeitsweise, die von einem Team verlangt, die Person mit dem Problem kennenzulernen, bevor es zur Lösung springt.

Laut Tim Brown, dem früheren CEO von IDEO, ist Design Thinking ein menschenzentrierter Ansatz für Innovation, der sich aus dem Werkzeugkasten der Designer speist. IDEO sagt, dass dieser Ansatz drei Dinge zusammenbringt: was Menschen wollen, was ein Unternehmen tragen kann und was Technik möglich macht.

Sarah Gibbons von der Nielsen Norman Group definiert Design Thinking dagegen als Ideologie, die von einem Prozess gestützt wird. Diese Unterscheidung halte ich für wichtig, denn Phasen auswendig zu lernen ist leicht. Schwer ist, die Sichtweise im Team zu verankern.

Laut Gibbons prägten David Kelley und Tim Brown von IDEO sowie Roger Martin den Begriff in den 1990er-Jahren. Gute Designer nutzten einen menschenzentrierten kreativen Prozess schon lange vorher. Der Begriff fasste über Jahre gereifte Methoden in einem Konzept zusammen und machte daraus einen Rahmen für geschäftliche Probleme.

Die Phasen des Design Thinking

Die verbreitetste Darstellung sind die fünf Phasen der Stanford d.school. Die d.school nennt sie nicht Phasen, sondern „Modi“, und gibt in ihrem Design Thinking Bootleg von 2018 Methodenkarten für jeden Modus. In der Einleitung des Decks steht auch, dass man beginnen kann, wo man will.

1. Empathie

Die d.school sieht Empathie als Grundlage menschenzentrierten Designs. Das Problem, das Sie lösen wollen, ist selten Ihr eigenes, sondern das bestimmter Nutzer. Deshalb beobachten Sie Nutzer in ihrer Umgebung, sprechen mit ihnen und erleben eine Zeit lang selbst, was sie erleben.

2. Definieren

Was Sie in der Empathiephase gesammelt haben, übersetzen Sie in Bedürfnisse und Erkenntnisse und schreiben am Ende eine Problemstellung, mit der sich arbeiten lässt. Die d.school nennt diesen Satz Point of View (POV). Er beschreibt nicht eine demografische Gruppe, sondern einen bestimmten Nutzer.

3. Ideen finden

In dieser Phase geht es um Breite: Die d.school will viele und möglichst verschiedene Ideen. Die Karten warnen deutlich: Bewerten Sie beim Ideenfinden nicht. Laut d.school entstehen innovative Ideen oft aus den ungewöhnlichsten.

4. Prototyp

Ein Prototyp holt die Idee aus dem Kopf und macht sie greifbar. Laut d.school kann das eine Wand voller Haftzettel, ein Rollenspiel oder ein Gegenstand sein. In der frühen Phase bleibt er günstig und grob; bei einem digitalen Produkt heißt das oft Papierbildschirm oder ein klickbarer Prototyp.

5. Test

Sie bringen den Prototyp in die Umgebung der Nutzer und holen Rückmeldung. Die Karte der d.school enthält eine Warnung: Ein Test zeigt manchmal nicht nur, dass die Lösung falsch ist, sondern auch, dass das Problem falsch definiert war. Dann schreiben Sie Ihren POV-Satz neu.

Sechste Phase: umsetzen

Im Rahmen von NN/g gibt es eine sechste Phase: umsetzen. Gibbons hält sie für die wichtigste und am häufigsten vergessene. Kommt die Idee aus dem Workshop nicht ins Produkt, bleibt nur ein schöner Tag.

Laut NN/g folgen die Phasen keiner geraden Linie, sie wiederholen sich und bilden einen Kreislauf. Nach dem Test eines Prototyps kehren Teams oft zu Empathie und Definieren zurück.

Phasenkarte: die Termin-App eines Bürgeramts

Statt die fünf Phasen abstrakt zu erklären, zeige ich sie an einem einzigen Szenario. In der Termin-App eines Bürgeramts erscheint zu einem Teil der gebuchten Termine niemand. Das Team weiß nicht, warum.

Phasenkarte

Phase 1 / 5

Empathie

Ziel

Die Person kennenlernen, die das Problem erlebt. Die d.school verlangt in dieser Phase drei Dinge: die Nutzer in ihrer Umgebung beobachten, mit ihnen sprechen und eine Zeit lang selbst erleben, was sie erleben.

Beispielaktivität

Das Team spricht zu zweit mit Bürgerinnen und Bürgern, die im Bürgeramt warten. Eine Person fragt, die andere schreibt mit. Die Frage lautet nicht „Wie buchen Sie normalerweise einen Termin?“, sondern „Erzählen Sie von dem Tag, an dem Sie zuletzt einen Termin gebucht haben?“. Ein Teammitglied bucht den Termin außerdem von vorn, als würde es die App gar nicht kennen.

Ergebnis

Zitate, Beobachtungsnotizen und Fotos. Eine Beispielnotiz: „Den Termin hat mein Sohn gebucht, die Uhrzeit hat mir niemand gesagt.“

Phase 2 / 5

Definieren

Ziel

Die Notizen in Bedürfnisse und Erkenntnisse übersetzen. Am Ende steht ein Satz mit einer Sichtweise, auf die sich das Team einigt. Die d.school nennt ihn „Point of View“ (POV).

Beispielaktivität

Das Team hängt die Notizen an die Wand und gruppiert ähnliche. Dann schreibt es diesen Satz: „Wir haben eine ältere Bürgerin getroffen, die ihren Termin von ihrem Sohn buchen lässt. Wir waren überrascht, dass die Termindaten sie nie erreichen.“ Danach werden aus diesem Satz „Wie könnten wir …?“-Fragen abgeleitet.

Ergebnis

Ein POV-Satz und einige „Wie könnten wir …?“-Fragen. Zum Beispiel: „Wenn jemand anderes bucht, wie könnten wir die Person informieren, die hingeht?“

Phase 3 / 5

Ideen finden

Ziel

Viele und möglichst verschiedene Ideen sammeln. Dabei werden Ideen nicht bewertet. Ausgewählt wird erst, wenn das Sammeln vorbei ist.

Beispielaktivität

Das Team schreibt die „Wie könnten wir …?“-Frage an die Tafel und macht ein halbstündiges Brainstorming. Jede Idee kommt auf einen Haftzettel. Es entstehen Ideen wie ein Feld „Wer geht hin?“ bei der Buchung, ein Anruf statt einer SMS oder die Terminbuchung im Bürgerbüro vor Ort. Am Ende stimmen alle ab.

Ergebnis

Eine Wand voller Zettel und zwei, drei per Abstimmung gewählte Ideen.

Phase 4 / 5

Prototyp

Ziel

Die Idee aus dem Kopf holen und greifbar machen. In der frühen Phase ist der Prototyp günstig und grob, so lernt man schnell.

Beispielaktivität

Der Schritt „Person hinzufügen, die hingeht“ wird auf Papier gezeichnet. Für die Erinnerung wird kein Code geschrieben: Die Person glaubt, die Nachricht kommt vom System, aber ein Teammitglied schickt sie von Hand. Die d.school nennt das einen Wizard-of-Oz-Prototyp.

Ergebnis

Papierbildschirme und ein von Hand gesteuertes Erinnerungsszenario. Beides ist an einem Nachmittag fertig.

Phase 5 / 5

Test

Ziel

Den Prototyp in die echte Umgebung der Nutzer bringen und Rückmeldung holen. Laut d.school ist ein Test die Gelegenheit, sowohl die Lösung als auch die Nutzer besser zu verstehen.

Beispielaktivität

Am Schalter bekommen einige Personen den Papierprototyp, ohne viel Erklärung. Das Team beobachtet, ohne einzugreifen, und fragt dann „Warum?“. Am Ende des Tages macht das Team eine Runde „Mir gefällt, ich wünsche mir, was wäre, wenn“.

Ergebnis

Eine Liste, was funktioniert und was nicht. Wenn nötig, ein neu geschriebener POV-Satz und die Entscheidung für die nächste Runde.

Das Szenario ist erfunden: die Termin-App eines Bürgeramts und Termine, die leer bleiben, weil Bürger nicht erscheinen. Drücken Sie auf eine Phase, dann zeigt die Karte darunter Ziel, Beispielaktivität und Ergebnis dieser Phase. Die Ziele sind meine Zusammenfassung der Karten aus dem Design Thinking Bootleg der d.school.

Achten Sie im Szenario auf die Phase Definieren. Hätte das Team mit „Bauen wir eine Erinnerungs-SMS ein“ begonnen, hätte es die Bürgerin, die ihren Termin buchen lässt, nie gesehen. Das richtige Problem kam aus den Empathie-Notizen.

Wie man es im Workshop anwendet

Sichtbar wird Design Thinking vor allem im Workshop: Menschen aus verschiedenen Abteilungen schauen im selben Raum auf dieselbe Frage. Die Karten im Deck der d.school sind kleine Werkzeuge für genau diese Arbeit. Diese nutze ich am häufigsten.

Anfängergeist

Die d.school rät dem Team, sein Wissen beiseitezulegen und das Problem mit neuen Augen zu sehen. Nicht urteilen, alles hinterfragen, wirklich neugierig sein. Im Bürgeramt-Szenario heißt das, die Annahme „Die Bürger bekommen doch schon eine SMS“ zu hinterfragen.

Empathie-Interview

Die Ratschläge der Karte sind einfach, werden aber oft missachtet. Fragen Sie nicht nach „normalerweise“, sondern nach einem bestimmten Moment: „Erzählen Sie, wann Sie zuletzt … gemacht haben?“ Achten Sie auf Widersprüche zwischen dem, was die Person sagt, und dem, was sie tut, und haben Sie keine Angst vor Schweigen.

Die d.school empfiehlt, Interviews zu zweit zu führen: Eine Person spricht, die andere schreibt mit. Sprechen Sie auch mit extremen Nutzern, denn laut den Karten machen ihre übersteigerten Bedürfnisse sichtbar, was bei durchschnittlichen Nutzern untergeht. Nach den Interviews hilft eine Persona, die Befunde ins Team zu tragen.

„Wie könnten wir …?“-Fragen

Die d.school nennt diese Fragen „How might we“. Die Frage muss breit genug sein, um Ideen anzustoßen, und eng genug, um dem Team Grenzen zu setzen. Mit dem Beispiel aus dem Deck: das Dessert neu zu gestalten ist zu breit, eine Eiswaffel, die nicht tropft, zu eng.

Brainstorming

Die Karte empfiehlt, dass das Team 15 bis 30 Minuten vor der Tafel nur Ideen sammelt. In dieser Zeit sortiert niemand Ideen aus. Jede Idee kommt auf einen eigenen Haftzettel, ausgewählt wird später.

Test mit Nutzern

Die d.school will, dass Sie den Prototyp nicht erklären, sondern den Nutzern in die Hand geben und sie nicht sofort korrigieren. Beobachten Sie, wie sie ihn nutzen und wie sie ihn falsch nutzen. Fragen Sie dann: „Zeigen Sie mir, warum das für Sie funktionieren würde oder nicht?“

Für eine strukturiertere Runde sehen Sie sich den Ratgeber zum Usability-Test an.

Nach dem Test mag ich für das Team die Runde „Mir gefällt, ich wünsche mir, was wäre, wenn“. Alle sprechen in kurzen Stichpunkten, und nicht jeder Punkt braucht eine Antwort. Die Karte findet dieses Werkzeug fast zu einfach, um es aufzuschreiben, aber zu nützlich, um es auszulassen.

Wie ich einen eintägigen Workshop aufbaue

Am Morgen lesen wir gemeinsam die Interviewnotizen und, falls vorhanden, eine Customer Journey Map. Vor dem Mittag schreiben wir den POV-Satz und die „Wie könnten wir …?“-Fragen. Am Nachmittag sammeln wir Ideen und zeichnen Papierprototypen.

Die letzte Stunde des Tages gebe ich echten Nutzern. Gibt es keine, verschiebt sich der Test auf den nächsten Tag, fällt aber nie weg. In einem Workshop, der ohne Nutzer endet, hat das Team nur seine eigenen Annahmen bestätigt.

Unterschied zu UX-Design und Double Diamond

Diese drei Begriffe werden oft verwechselt, weil sich die Namen der Phasen ähneln. Meine Unterscheidung: Design Thinking ist eine Denkweise und Workshop-Praxis, UX-Design ist die Arbeit, die ein Produkt über Wochen und Monate voranbringt. Der Double Diamond ist ein Modell, das diese Arbeit beschreibt.

Den Produktprozess Schritt für Schritt beschreibe ich im Ratgeber UX-Design. Das Modell des Design Council behandle ich gesondert auf der Seite Double Diamond. Die Geschichte auf der Seite des Design Council beginnt 2003 mit der Suche nach einer einheitlichen Sprache für den Designprozess.

Kritik

Design Thinking hat ebenso starke Kritiker wie Befürworter. Alle Positionen unten habe ich in der Quelle gelesen.

„Ein nützlicher Mythos.“ Don Norman nannte 2010 in seinem Beitrag bei Core77 die Vorstellung einen Mythos, Designer hätten eine geheimnisvolle Denkweise, die allen anderen überlegen sei. Ihm zufolge war Design Thinking ein PR-Begriff für gutes, altmodisches kreatives Denken. Trotzdem fand er den Begriff nützlich: Er zeigte, dass Designer mehr tun, als Dinge „hübsch zu machen“.

Die Gegenantwort. Bill Moggridge antwortete Norman im selben Jahr bei Core77. Für ihn ist das Etikett Design Thinking kein Mythos, und die sich wiederholende Struktur des Prozesses war immer da. Den Prozess kann jeder nutzen, unabhängig vom Hintergrund; am meisten hilft er am Anfang, wenn entschieden wird, was getan werden soll.

Normans Kehrtwende. Norman änderte seine Sicht 2013 im Beitrag „Rethinking Design Thinking“ teilweise. Er schrieb, dass Design Thinking tatsächlich etwas Besonderes sei, fügte aber hinzu, dass es nicht nur Designern gehöre. Das Hinterfragen von Annahmen stellte er in den Mittelpunkt.

Der Designer im Mittelpunkt. Natasha Iskander von der NYU argumentierte 2018 in der Harvard Business Review, Design Thinking sei im Kern konservativ. Ihr zufolge bewahrt die Methode den Status quo und stellt den Designer über die Menschen, denen er dient.

Die vergessene Umsetzung. Das ist keine Kritik von außen, sondern die eigene Warnung von NN/g. Gibbons hält die Umsetzungsphase für die wichtigste und am häufigsten vernachlässigte. Eine Wand voller Haftzettel ersetzt keine einzige Änderung, die ins Produkt geht.

Meine Notiz

Ich sehe Design Thinking nicht als Methode, sondern als Gewohnheit. Beginnt das Team im ersten Meeting über Lösungen zu sprechen, frage ich: „Von wem haben wir das gehört?“ Gibt es keine Antwort, sprechen wir zuerst mit einigen Nutzern.

Iskanders Kritik halte ich für berechtigt. Ein Empathie-Interview ersetzt nicht, die Nutzer mit in den Entscheidungsraum zu holen. Deshalb lade ich zu Workshops nach Möglichkeit echte Nutzer ein oder das Support-Team, das täglich mit ihnen spricht.

Die meisten Ideen aus einem Workshop kommen nicht ins Produkt, das ist normal. Mein Maßstab: Hat es in den zwei Wochen nach dem Workshop mindestens eine Idee vom Prototyp in den Code geschafft? Wenn nicht, haben wir keinen Workshop gemacht, sondern eine Vorführung. Diesen Übergang beschreibe ich im Ratgeber Design-Handoff.