Die Haltung der Moderation: auf der Bremse stehen
Design Thinking ist keine Ausrede, um mit Haftnotizen zu spielen. Es ist ein konsequenter, strukturierter Ansatz, um sehr unklare Probleme zu lösen, indem man die Endnutzer wirklich versteht. Als Moderation dieses Prozesses musst du die „Bremse“ im Raum sein. Teams sind von Natur aus darauf gepolt, zu Lösungen zu eilen, besonders wenn viele Entwickler, Leute aus dem operativen Geschäft oder Führungskräfte im Raum sitzen. Deine wichtigste Aufgabe ist, gegen diesen Instinkt anzukämpfen. Du musst das Team zwingen, in der unbequemen, trüben Unklarheit des Problemraums zu bleiben, bis der wahre Kern des Problems der Nutzer unbestreitbar wird. Wenn das Team zu einer Lösung springen will, bevor es die Not der Nutzer ganz verstanden hat, musst du es bestimmt zurückholen.
Wann das Framework wirklich funktioniert (und wann es scheitert)
Am wirksamsten ist dieser Workshop, wenn du vor einem „bösartigen“ Problem stehst, einem sogenannten Wicked Problem. Das sind Herausforderungen, die notorisch schlecht definiert sind, für die es in deiner Organisation kein klares Vorbild gibt oder die stark von komplexem menschlichem Verhalten abhängen. Ein Beispiel: herauszufinden, wie sich ein hochtechnisches Onboarding für Nutzer ohne technischen Hintergrund weniger einschüchternd anfühlt.
Design Thinking ist der richtige Eingriff, wenn sich eure aktuellen Lösungen abgestanden anfühlen oder wenn du vermutest, dass sie auf internen Annahmen und Unternehmenspolitik beruhen statt auf belastbaren Erkenntnissen über die Nutzer. Außerdem ist es ein hervorragendes Mittel, um festgefahrene Abteilungssilos aufzubrechen, oder wenn ein Team in einer „Business as usual“-Schleife feststeckt und dringend echte, querdenkende Innovation braucht. Es scheitert allerdings, wenn das Problem rein technisch ist oder die Lösung schon feststeht und der Workshop nur als Theater dient, um Zustimmung einzuholen.
Die richtigen Leute einladen und den Rahmen setzen
Die Magie eines Design-Thinking-Workshops entsteht ganz aus radikaler, bereichsübergreifender Zusammenarbeit. Ziel ist eine kleine Gruppe von fünf bis acht Teilnehmenden. Zu dieser Gruppe muss unbedingt ein „Decider“ gehören: die Person mit der letzten Entscheidungsbefugnis und dem Budget, um das Projekt freizugeben, damit das Ergebnis nicht in der Schublade landet. Du brauchst auch jemanden mit Kundenexpertise, etwa aus dem Kundensupport an vorderster Front oder aus der UX-Forschung, der jeden Tag mit den Endnutzern spricht und ihre echte, ungeschönte Sprache kennt. Ergänze die Runde um „Builder“, die die technischen und finanziellen Grenzen kennen und die Ideen auf dem Boden halten, und um einen „Joker“ aus einer völlig fachfremden Abteilung, der einen frischen, unvoreingenommenen Blick mitbringt.
Versuch keine Design-Thinking-Session ohne qualitative Rohdaten; mit einer Tabelle oder einem Tortendiagramm kann man nicht mitfühlen. Noch bevor die Session beginnt, sollte jede teilnehmende Person mindestens ein aufgezeichnetes Nutzerinterview ansehen oder einen Stapel unbearbeiteter Support-Tickets lesen. Genauso wichtig: Mach ausdrücklich klar, dass alle ihr Ego, ihren Titel und ihre Annahmen an der Tür abgeben. Sie sind da, um herauszufinden, was stimmt, nicht um zu bestätigen, was sie ohnehin für richtig halten.
Durch das Chaos steuern: die Durchführung
Eine typische Session dauert einen halben oder ganzen Tag und geht methodisch durch vier klar getrennte Phasen. Sie beginnt mit der Empathie-Phase (Empathize): Das Team taucht in die Nutzerdaten ein, um eine klare, menschenzentrierte Problemstellung zu formulieren. Klingt diese Problemstellung wie eine technische Anforderung, etwa „Wir brauchen eine schnellere Datenbank“, musst du das Team zwingen, sie aus Sicht der Nutzer neu zu schreiben, etwa „Die Nutzerin bricht den Kauf ab, weil sie beim langen Ladebildschirm um ihre Kreditkarte fürchtet“.
Danach geht das Team in die Phase der Ideenfindung (Ideate) und brainstormt divergent. Hier musst du die Improvisationsregel „Ja, und …“ gnadenlos durchsetzen, um zerbrechliche, frühe Ideen vor vorschneller Kritik zu schützen. Zum Schluss wechselt das Team in die Prototyp- und Testphase (Prototype and Test). Dort muss es aufhören zu reden und anfangen, einfache Prototypen aus billigen Materialien wie Papier oder Wireframes zu bauen und sie sofort an der Realität zu testen.
Den Durchbruch herbeiführen
Während der ganzen Session musst du das Team mit scharfen, unbequemen Fragen intellektuell ehrlich halten. Hinterfrage ständig, ob es das Problem wirklich für die Nutzer löst oder nur eine Lösung entwirft, die die eigenen internen Abläufe einfacher macht. Lass es die riskanteste Annahme hinter seiner Lieblingsidee benennen, oder frag, wie es das Problem lösen würde, wenn es null Budget und nur eine Woche bis zum Launch hätte. Wenn jemand eine Idee scharf kritisiert, lass sie nicht einfach abschießen; zwing die Person, zu benennen, unter welchen konkreten Marktbedingungen diese Idee doch funktionieren würde.
Bleib sehr wachsam gegenüber typischen Fehlern. Der gefährlichste ist, die Empathie-Phase ganz zu überspringen und direkt zur Ideenfindung zu eilen. Das führt immer wieder dazu, dass ein Team brillant das falsche Problem löst. Du musst auch gegen die „Ja, aber …“-Haltung ankämpfen, den absoluten Killer früher Ideenfindung. Schütze den Prozess vor „Design by Committee“, bei dem mutige Ideen zusammengemischt werden, damit alle zufrieden sind, und am Ende verwässerte, mittelmäßige Lösungen herauskommen; gib stattdessen dem Decider die Befugnis, die letzte, harte Entscheidung zu treffen. Und verhindere, dass das Team seine Prototypen zu kompliziert macht. Das Ziel ist, schnell zu lernen, nicht perfekt zu bauen.
Mehr aus der Session herausholen
Zwei Kniffe vertiefen diesen Prozess. Lass in der Empathie-Phase ein Teammitglied in einem simulierten Interview die Ziel-Persona spielen, damit der Rest des Teams üben kann, nach Schmerzpunkten zu fragen, bevor es mit echten Nutzern spricht. Bestimme in der Ideenfindung jemanden, der den Advocatus Diaboli spielt und die Ideen mit Randfällen und strukturellen Schwächen auf die Probe stellt, bevor ihr mit dem Prototyping beginnt.
Das Artefakt, das in dieser Session entsteht, ist kein kostbares Objekt, das verteidigt werden muss; es ist nur eine Hypothese, die darauf wartet, getestet zu werden. Der Auftrag beim Verlassen des Raums lautet: die einfachen Prototypen echten Nutzern vorlegen, so schnell und günstig wie möglich scheitern und die ungefilterten Erkenntnisse in die nächste Iteration mitbringen. Die eigentliche Arbeit beginnt in dem Moment, in dem das Team sein Ego an der Tür abgibt und sich in die Lage seiner Nutzer versetzt.
