Der Name „Design Thinking“ lässt schnell vermuten, dass es bei diesem Konzept hauptsächlich um kreatives Arbeiten und vor allen Dingen um Design geht – aber das ist nur die eine Seite der Medaille. In meinem Blogpost „Was ist eigentlich Design Thinking?“ habe ich bereits einiges über das tatsächlich dahinter stehende Mindset geschrieben. Jetzt möchte ich weiter ins Detail gehen und euch die Phase vorstellen, in der die wichtige Vorarbeit für die richtig guten Lösungen geleistet werden muss: die Define-Phase.
Die Define-Phase – was war das gleich nochmal?
Wenn ihr in die Define-Phase eintaucht, dann kommt ihr gerade aus der sogenannten Empathize-Phase und habt sehr, sehr viel Input über eure Nutzer gesammelt. Ihr habt interviewt, Beobachtungen durchgeführt und euch in die Lage eurer Nutzer hineinversetzt. Egal, welche der Methoden ihr eingesetzt habt, eins ist sicher: Die Menge an gewonnenen Informationen ist hoch – und das ist auch gut so.
Ihr müsst euch das so vorstellen: Wenn ihr euch vorher intensiv mit euren Nutzern beschäftigt habt, dann ist es sehr wahrscheinlich, dass unter dieser Menge an Informationen das eine Informationselement ist, das ein Kernbedürfnis eurer Nutzer darstellt – und dieses ist die notwendige Basis und der Schlüssel, um später gute Endergebnisse und erfolgreiche Lösungen aus eurem Design-Thinking-Prozess zu ziehen. Wichtig ist jetzt nur, dieses einzelne Informationsstück zu finden. In der Define-Phase geht es also darum, die gesammelten Informationen zu aggregieren, zu ordnen und zu bewerten – und sich schließlich auf eine ganz konkrete Fragestellung im Team zu committen, die dann weiterverfolgt wird.
Wie findet ihr die (eine) Frage, die euch zu einer erfolgreichen Lösung führt?
Es gibt sicherlich viele verschiedene Wege, um mit den gewonnenen Informationen über eure Nutzer weiterzuarbeiten – z. B. die „Customer Job Map“ und „How might we“-Fragen. Um die Methode der „Customer Job Map“ zu verstehen, muss man allerdings erst einmal das dahinterstehende Grundprinzip kennen: die „Jobs to be done“.
Was sind “Jobs to be done”?
Als ich mit dem Thema „Jobs to be done“ in Berührung gekommen bin, las ich im „Digital Innovation Playbook“ von Dark Horse Innovation über ein Beispiel, das ich sehr spannend fand. Sie berichteten von der Studie einer Fast-Food-Kette, die den Absatz ihrer Milchshakes verbessern wollte. Zunächst gingen sie ganz klassisch vor: Sie nutzten die Daten über ihre Kunden, packten sie in Kundensegmente und befragten sie in Bezug auf den idealen Milchshake. Die Erkenntnisse änderten den Absatz allerdings nicht wirklich. Die Fast-Food-Kette beauftragte daraufhin einen User Researcher von Professor Clayton Christensen, der einen ganzen Tag lang eine Beobachtung vor Ort durchführte. Er notierte sich alle wichtigen Informationen, wie z. B. wann die Milchshakes gekauft wurden. Die erste Erkenntnis war, dass die meisten Milchshakes früh morgens zum Mitnehmen über die Ladentheke gingen.
Am nächsten Tag führte der User Researcher Interviews mit den Kunden durch, die einen solchen Milchshake kauften. Es stellte sich heraus, dass die Kunden den Milchshake nicht etwa wegen seines Geschmacks kauften, sondern dass dieser einen ganz anderen „Job“ hat. Da ihr Weg zur Arbeit sehr langweilig war, brauchten sie etwas, um sich zu beschäftigen (Job 1). Außerdem wollten sie etwas zu sich nehmen, das ihren Hunger bis zum Mittag stillt (Job 2).
Wenn man – wie in diesem Fall – den tatsächlichen Job (to be done) hinter dem Verhalten von Personen identifiziert, ist eine gute Lösung nicht mehr weit entfernt. Und genau das ist unser Ziel in der Define-Phase.
Die Customer Job Map
Die Voraussetzungen, um die Jobs to be done aufzudecken, sind natürlich gute Interviews und Beobachtungen, in denen ihr genau erfahrt, in welchen Situationen eure Nutzer was aus welcher Motivation heraus tun. Mit diesen Informationen könnt ihr nun in der Define-Phase sogenannte „Job Stories“ formulieren. Diese haben die folgende Struktur:
When [Situation], I want [Motivation], so that [Outcome].
Bezogen auf unser Milchshake-Beispiel wären beispielhafte Job Stories:
Wenn ich morgens zur Arbeit pendle, möchte ich eine Beschäftigung haben, sodass mir auf der Fahrt nicht langweilig wird.
oder
Wenn ich morgens zur Arbeit pendle, möchte ich etwas zu mir nehmen, das mich lange satt macht, sodass ich nicht direkt nach meiner Ankunft wieder hungrig bin.
Diese Job Stories könnt ihr jetzt noch mit Zusatzinformationen, wie Ankern (was hält den Nutzer zurück, dieses gesetzte Ziel zu erreichen) und Raketen (was bringt dem Nutzer schneller seinem Ziel entgegen) anreichern.
Durch die Information in der Job Story ergibt sich zudem bereits eine zeitliche Abfolge, anhand derer ihr die Stories ordnen könnt – ähnlich wie man es auch bei einer Customer Journey Map tun würde. Wir haben gute Erfahrungen damit gemacht, hier das „5 E Experience Modell“ mit seinen Phasen Excitement, Entry, Engagement, Exit und Extension zu nutzen, um sämtliche Situationen zu erfassen, die die Nutzer vor, während und nach dem Kontakt mit dem Produkt durchlaufen. Ihr könnt die einzelnen Stories so auf einen Zeitstrahl bringen und ggf. verknüpfen. Daraus ergibt sich die „Customer Job Map“.
Wie geht es weiter? – Die „How might we“-Frage
Jetzt habt ihr die Customer Job Map – aber wie kommt ihr von hier weiter in die Ideate-Phase? Zum Beispiel mit dem Konzept der „How might we“-Frage. Ihr schaut euch alle eure Job Stories mit ihren Ankern und Raketen an und stellt euch die Frage, wie ihr die dahinter stehenden Bedürfnissen erfüllen oder die Probleme lösen könnt. Diese Fragen schreibt ihr explizit auf und hängt sie zum jeweils zugehörigen Element in der „Customer Job Map“. Wichtig ist, dass die Fragen kein „ob“, sondern ein „wie“ beinhalten: Ihr stellt gar nicht erst in Frage, ob ihr das Problem lösen könnt oder nicht – ihr geht einfach davon aus, dass ihr es könnt und fragt nur nach dem Wie.
(Customer Job Map mit zugeordneten "How might we"-Fragen)
Auf unser Milchshake-Beispiel bezogen könnte eine mögliche „How might we“- Frage lauten:
Wie können wir unsere Milchshakes so gestalten, dass die Nutzer von diesen auf dem Weg zur Arbeit unterhalten werden?
Es können sich hier natürlich noch viele weitere Fragen ergeben. Wichtig ist danach, dass ihr euch nun nach der Sammlung der Fragen im Team auf eine oder zwei Fragestellungen fokussiert, mit denen ihr kreativ weiterarbeiten wollt. Am besten eignet sich hierfür ein Voting im Team. Meist zeigt sich hier bereits, dass die Teilnehmer ein bestimmtes Bauchgefühl für vielversprechende Fragestellungen haben und viele der Votes auf eine bestimmte Fragestellung fallen.
Und damit hätten wir es: Die Basis für den Einsatz der Kreativmethoden in der Ideate-Phase ist gelegt.
Mein Fazit – harte Arbeit, die sich lohnt
Die Define-Phase ist meiner Erfahrung nach sicherlich die anstrengendste. Wer einmal die Aussage hört „Design Thinking ist doch nur Spaß“ hat sicherlich in gewisser Weise Recht. Ich würde aber eher sagen: „Design Thinking ist harte Arbeit (und etwas Spaß)“. Ich erinnere mich da gerne an unseren letzten zwei-tägigen Design-Thinking-Workshop, an dem wir uns am ersten Tag mit der Empathize- und Define-Phase beschäftigt haben und am Ende des Tages alle Teilnehmer wirklich geschlaucht waren. Gleichzeitig war es großartig zu sehen, wie wir uns Schritt für Schritt dem Kern unseres Problem genähert und es genau definiert haben.
Führt euch also genau das immer vor Augen: Wenn ihr in diese beiden Phasen richtig viel investiert, erntet ihr in den nächsten Phasen ziemlich leicht die Früchte und stellt am Ende fest, dass ihr eine Lösung gefunden habt, die das Team begeistert – und höchstwahrscheinlich auch eure Nutzer.
Kommentare