Design Thinking Schritt für Schritt und wo es schiefgeht

Design Thinking ist eine Art, Probleme zu lösen, die bei den Menschen beginnt, die sie haben. In der Praxis läuft es in fünf Schritten ab: die Menschen verstehen, das Problem definieren, Ideen entwickeln, einen groben Prototyp bauen und ihn mit echten Nutzerinnen und Nutzern testen, wobei Sie immer dann zurückspringen, wenn der Test Ihnen etwas beibringt. Die Schritte sind einfach; Teams scheitern an vorhersehbaren Stellen, und dieser Artikel zeigt, wo und wie Sie jede davon vermeiden.

Die Fünf-Schritte-Version wird an der Stanford d.school gelehrt (Empathie, Definieren, Ideen finden, Prototyp, Testen). Der Double Diamond des britischen Design Council, 2003 entwickelt und ab 2004 öffentlich geteilt, beschreibt denselben Weg in vier Phasen: Discover, Define, Develop, Deliver. Nutzen Sie das Vokabular, das Ihre Organisation bereits kennt. Entscheidend ist die Reihenfolge der Fragen, nicht die Namen auf den Folien.

Wenn Sie noch entscheiden, ob Design Thinking überhaupt der richtige Ansatz ist, lesen Sie zuerst Design Thinking vs. Lean vs. Agile vs. Design Sprint. Den größeren Überblick über die Methoden finden Sie in Welche Innovationsmethode passt?.

Bevor Sie beginnen: die Aufgabe aufsetzen

Design Thinking scheitert am häufigsten vor dem ersten Schritt. Klären Sie drei Dinge vor dem ersten Interview.

1. Ein Sponsor, dem die Entscheidung gehört. Benennen Sie die Person, die auf Grundlage des Ergebnisses handeln wird. Wenn niemand Ja zum Ergebnis sagen kann, produziert das Projekt einen Bericht.
2. Ein Briefing, das ein Problemfeld benennt, keine Lösung. „Verbessern, wie neue Mitarbeitende durch ihren ersten Monat kommen“ ist ein Briefing. „Eine Onboarding-App bauen“ ist eine getarnte Lösung und schließt das Projekt, bevor es begonnen hat.
3. Ein kleines, gemischtes Kernteam und geschützte Zeit. Vier bis sechs Personen, darunter jemand, der den Service im Alltag erbringt. Ein halber Tag pro Woche über sechs Wochen schlägt eine heroische dreitägige Klausur, auf die niemand aufbaut.

Schritt 1: Die Menschen verstehen (Empathie)

Was Sie tun. Gehen Sie zu den Menschen, die mit dem Problem leben. Führen Sie Stakeholder-Interviews mit acht bis zwölf Personen aus der gesamten Bandbreite der Nutzer, nicht nur mit den freundlichen. Ergänzen Sie Kontextbeobachtung: Schauen Sie zu, wie die Aufgabe dort erledigt wird, wo sie anfällt.

Was dabei herauskommt. Notizen in den eigenen Worten der Menschen, Fotos der realen Umgebung und eine erste Empathy Map für jeden wichtigen Nutzertyp.

Wo es schiefgeht.

• Das Team befragt Kolleginnen oder Vorgesetzte über die Nutzer statt die Nutzer selbst.
• Die Fragen verlangen von Menschen, ihr künftiges Verhalten vorherzusagen („Würden Sie … nutzen?“), was sie schlecht können.
• Die Forschung wird ausgelagert, und das Team liest eine Zusammenfassung, statt die Menschen direkt zu hören. Das Umdenken passiert im Raum, nicht im Bericht.

Abhilfe. Fragen Sie nach dem letzten Mal, als etwas passiert ist („Erzählen Sie mir vom letzten Mal, als Sie …“), und sorgen Sie dafür, dass jedes Mitglied des Kernteams an mindestens zwei Interviews teilnimmt. Mehr dazu in 5 Forschungsfehler, die Ihre Interviews wertlos machen.

Schritt 2: Das Problem definieren

Was Sie tun. Legen Sie die Erkenntnisse aus und bündeln Sie sie mit einem Affinitätsdiagramm. Suchen Sie nach Spannungen und Überraschungen, nicht nur nach häufigen Beschwerden. Formulieren Sie ein Point-of-View-Statement: ein konkreter Nutzer, ein Bedürfnis und eine Erkenntnis, warum es wichtig ist. Machen Sie daraus zwei oder drei Wie-könnten-wir-Fragen.

Was dabei herauskommt. Eine abgestimmte Problemstellung und eine kurze Reihe von Wie-könnten-wir-Fragen, vom Sponsor freigegeben.

Wo es schiefgeht.

• Das Team überspringt diesen Schritt, weil „wir das Problem schon kennen“. Meist kennt es das Symptom.
• Die Aussage ist so breit („Wie könnten wir das Kundenerlebnis verbessern?“), dass jede Idee passt, oder so eng („Wie könnten wir einen Chatbot ergänzen?“), dass sie die Antwort gleich mitliefert.
• Der Sponsor bekommt die Aussage nicht zu sehen und lehnt später Ideen ab, weil er ein anderes Problem im Kopf hatte.

Abhilfe. Behandeln Sie die Freigabe der Problemstellung als Gate. Eine vollständige Anleitung finden Sie in Ihre Problemstellung ist das ganze Projekt.

Schritt 3: Ideen entwickeln

Was Sie tun. Beginnen Sie still. Nutzen Sie Brainwriting oder Crazy 8s, damit alle zuerst allein Ideen entwickeln, bevor die Gruppe diskutiert. Setzen Sie zuerst auf Menge. Dann bündeln Sie, bauen auf den Ideen der anderen auf und grenzen mit einer Impact-Effort-Matrix oder einem ähnlichen Werkzeug ein.

Was dabei herauskommt. Zwei oder drei Ideen, die einen Prototyp wert sind, jede verknüpft mit der Wie-könnten-wir-Frage, die sie beantwortet.

Wo es schiefgeht.

• Offene Diskussion ab der ersten Minute, sodass die ranghöchste oder lauteste Person die Richtung vorgibt.
• Das Team verliebt sich in eine Idee und hört auf, weitere zu entwickeln.
• Ideen werden per Handzeichen gewählt, ohne zu fragen, welche die Problemstellung am besten beantworten.

Abhilfe. Trennen Sie Entwickeln und Bewerten, zeitlich und in den Regeln. Warum offenes Brainstorming nicht funktioniert und was Sie stattdessen nutzen können, lesen Sie in Brainstorming funktioniert nicht; das hier schon.

Schritt 4: Prototyp bauen

Was Sie tun. Bauen Sie das Günstigste, was einen echten Menschen auf die Idee reagieren lässt. Ein Papierprototyp eines Bildschirms oder Formulars, ein Storyboard eines Service, ein nachgebauter Brief, ein im Rollenspiel durchgespieltes Schaltergespräch. Listen Sie vor dem Bauen mit Assumption Mapping die riskantesten Annahmen auf und stellen Sie sicher, dass der Prototyp sie testet.

Was dabei herauskommt. Ein grober Prototyp pro Idee und eine schriftliche Notiz, was Sie daraus zu lernen erwarten.

Wo es schiefgeht.

• Der Prototyp ist zu ausgefeilt. Menschen sind höflich zu Dingen, die fertig aussehen, und hören auf, ehrliches Feedback zu geben, und das Team zögert, Arbeit wegzuwerfen, die Wochen gedauert hat.
• Der Prototyp testet den einfachen Teil (das Aussehen des Bildschirms) statt des riskanten (ob überhaupt jemand die richtigen Unterlagen mitbringen würde).
• Die IT oder ein Dienstleister wird beauftragt, einen Pilot zu bauen, und das Projekt wird unbemerkt zur Implementierung.

Abhilfe. Setzen Sie ein Zeitlimit von ein oder zwei Tagen für einen Prototyp. Dauert es länger, ist er zu detailliert.

Schritt 5: Testen, dann eine neue Schleife

Was Sie tun. Legen Sie den Prototyp etwa fünf echten Nutzerinnen und Nutzern vor. Führen Sie einen Moderierten Usability-Test durch: Geben Sie eine Aufgabe, beobachten Sie und schweigen Sie. Halten Sie die Ergebnisse in einem Feedback-Capture-Grid fest: was funktioniert hat, was nicht, aufgeworfene Fragen, neue Ideen.

Was dabei herauskommt. Eine klare Entscheidung für jede Idee: verfeinern, verwerfen oder in einen Pilot überführen. Oft lernen Sie auch, dass das Problem leicht falsch formuliert war, was Sie zurück zu Schritt 2 schickt.

Wo es schiefgeht.

• Das Team erklärt den Prototyp vor dem Test und misst dann, wie gut die Menschen die Erklärung verstanden haben.
• Der Test wird wie eine Abschlussprüfung behandelt, die bestanden werden muss, sodass negative Ergebnisse wegerklärt werden.
• Nach dem Test gibt es keinen Weg in die Umsetzung, und der Prototyp landet in der Schublade.

Abhilfe. Vereinbaren Sie vorab, welches Ergebnis Sie die Idee verwerfen ließe. Und klären Sie vor dem Test mit dem Sponsor, wer eine erfolgreiche Idee in die Umsetzung bringt und aus welchem Budgetposten.

Ein Praxisbeispiel

Illustrativ. Eine Universitätsbibliothek in einer Großstadt möchte, dass mehr Studierende ihren Service zur Forschungsunterstützung nutzen. Die Nutzung ist gering, und die Leiterin der Bibliotheksdienste vermutet, dass es an der Bekanntheit liegt.

Verstehen. Das fünfköpfige Team interviewt zehn Studierende und beobachtet an drei Nachmittagen die Auskunftstheke. Die Studierenden wissen, dass es den Service gibt. Was sie abhält: Für die Buchung müssen sie ihr Forschungsthema in einem Formular beschreiben, und viele haben das Gefühl, ihr Thema sei noch nicht „gut genug“, um es einer Bibliothekarin zu zeigen.

Definieren. Das Point-of-View-Statement lautet: „Masterstudierende im ersten Jahr brauchen eine niedrigschwellige Möglichkeit, früh um Hilfe zu bitten, weil sie sich beurteilt fühlen, solange ihre Forschungsidee noch unklar ist.“ Die Wie-könnten-wir-Frage: „Wie könnten wir es normal machen, um Hilfe zu bitten, bevor das Thema klar ist?“

Ideen entwickeln. Eine Brainwriting-Runde bringt vierzig Ideen. Nach der Impact-Effort-Matrix bleiben drei: offene Sprechstunden für „unklare Themen“, ein Buchungsformular mit nur einem optionalen Feld und Besuche von Bibliothekarinnen und Bibliothekaren im ersten Seminar jedes Studiengangs.

Prototyp. Ein gedrucktes Schild für die offene Sprechstunde und eine Papierversion des kürzeren Formulars, beides an einem Vormittag erstellt.

Testen. Innerhalb von zwei Wochen zieht die offene Sprechstunde einen stetigen Strom von Studierenden an, während das kürzere Formular kaum etwas verändert. Das Team verwirft das Formular, behält die offene Sprechstunde für einen semesterlangen Pilot und vereinbart mit der Leiterin der Bibliotheksdienste, welche Personalstunden ihn abdecken.

Die ursprüngliche Annahme, die Studierenden wüssten nichts von dem Service, hätte eine Plakatkampagne hervorgebracht. Der Prozess brachte eine andere Antwort.

Was Sie tun und was Sie lassen sollten

Tun

• Sichern Sie sich vor dem ersten Schritt einen benannten Sponsor und ein lösungsfreies Briefing.
• Lassen Sie das Kernteam die Nutzer direkt hören.
• Lassen Sie die Problemstellung vor der Ideenfindung freigeben.
• Bauen Sie Prototypen in Stunden, nicht in Wochen.
• Planen Sie den Weg in die Umsetzung, bevor Sie testen.

Lassen

• Behandeln Sie Design Thinking nicht als Workshop. Ein einzelner Tag kann die Ideenfindung abdecken; der vollständige Prozess dauert Wochen.
• Überspringen Sie den Definitionsschritt nicht, um Zeit zu sparen. Das kostet später mehr Zeit.
• Polieren Sie Prototypen nicht und erklären Sie sie nicht vor dem Test.
• Nutzen Sie den Prozess nicht, um eine bereits getroffene Entscheidung zu rechtfertigen. Die Menschen merken es, und Sie verlieren sie für das nächste Projekt.
• Verstehen Sie die Schritte nicht als streng linear. Zurückspringen heißt, dass die Methode funktioniert.

Häufige Fragen

Was sind die 5 Phasen des Design Thinking? Im Modell der Stanford d.school: Empathie, Definieren, Ideen finden, Prototyp und Testen. Der Double Diamond des Design Council fasst dieselbe Arbeit in vier Phasen zusammen: Discover, Define, Develop und Deliver.

Wie lange dauert ein Design-Thinking-Projekt? Für ein fokussiertes Serviceproblem sollten Sie mit vier bis zehn Wochen Teilzeitarbeit eines kleinen Kernteams rechnen. Ein Design Sprint kann die späteren Schritte auf fünf Tage verdichten, aber erst, wenn das Problem einigermaßen gut verstanden ist.

Warum scheitert Design Thinking in Organisationen? Meist aus organisatorischen Gründen, nicht methodischen: kein Sponsor, dem das Ergebnis gehört, ein Briefing, das die Lösung schon enthält, übersprungene oder ausgelagerte Forschung und kein Weg vom getesteten Prototyp in die Umsetzung.

Wie es weitergeht

Die Methodenleitfäden für jeden Schritt: Stakeholder-Interviews für Schritt 1, Point-of-View-Statement und Wie-könnten-wir-Fragen für Schritt 2, Brainwriting für Schritt 3 und Papierprototyp für die Schritte 4 und 5. Mehr zum Testen lesen Sie in Wie Sie eine Idee testen, bevor Sie sie bauen.