Design Thinking

Best Practices in der Definitionsphase des Design Thinkings

Lesedauer: etwa 6 Min.

Themen:

  • Kundenerlebnis

Design Thinking wird häufig von UX- und UI-Designern eingesetzt, die ein positives Kundenerlebnis schaffen möchten. Als kreativer, iterativer Prozess dient Design Thinking einem tieferen Verständnis der Zielgruppe, des Kunden und der Nutzende, für die ein Produkt entworfen werden soll.

Es gibt fünf Design Thinking Phasen, wobei jede einzelne auf dem vorherigen Schritt aufbaut. Das macht die zweite Phase, die Definitionsphase der Design Thinking Methode, besonders interessant: Sie folgt auf die erste Phase, Empathie. Jetzt bauen Sie auf den bereits gesammelten Daten auf und sehen die Ergebnisse Ihrer Grundlagenarbeit.

Wir begleiten Sie durch die zweite Design Thinking Phase, damit Sie zuversichtlich fortfahren können.

Zweite Design Thinking Phase: Was ist die Definitionsphase?

Angenommen, Sie veranstalten ein Meeting, um das größte Marketingproblem Ihres Unternehmens zu lösen. Es hat jedoch niemand genau definiert, was dieses Problem ist. Ihr Marketing-Team schlägt also vor, wie etwa E-Mail-Marketingprozesse, Social-Media-Marketingkonzepte und der schlechte Kaffee im Pausenraum verbessert werden könnten.

In dieser Design Thinking Phase wird zunächst das Problem ermittelt, das die Designer zu lösen versuchen. So werden alle auf den gleichen Stand gebracht. In dieser Phase wird das Problem auf optimale Weise definiert: möglichst breit, aber nicht unklar, und möglichst eng, aber nicht einschränkend. Am besten ist es, wenn das Problem am Ende in einem Satz zusammengefasst werden kann.

Vier grundlegende Fragen für die Definitionsphase

Das Problem aus verschiedenen Blickwinkeln zu untersuchen, ist der beste Weg, um zu verstehen, welche problematischen Faktoren dabei zusammenkommen. Das mag nach einer Herausforderung klingen, die eher kompliziert als hilfreich ist. Zum Glück gibt es ein paar Wegweiser, die Ihnen den Einstieg erleichtern. Die folgenden grundlegenden Fragen helfen Ihnen dabei, das Problem besser zu definieren.

  1. Wessen Problem ist es?
    Hier geht es um Ihre primäre Zielgruppe. Definieren Sie zunächst, welche Wünsche und Motivationen die Nutzende Ihrer Zielgruppe haben und wie sie mit Ihrem Produkt interagieren. Wenn Sie nicht wissen, wem Sie eigentlich helfen wollen, können Sie auch keinen Mehrwert für diese Personen schaffen.
  2. Welches Problem haben Nutzende wirklich? 
    Angenommen, Sie entwickeln eine Plattform, über die Nutzende Autos kaufen können. Vielleicht denken Sie, dass Sie das Problem Ihrer Nutzende lösen, indem Sie eine größere Auswahl an Kaufoptionen anbieten. Doch Ihrem Kernnutzende mangelt es möglicherweise nicht an Optionen, sondern eher an Entscheidungswillen. Sehen Sie sich die Problemstellen, die Sie in der Empathie Phase identifiziert haben, genauer an und ermitteln Sie die wahren Bedürfnisse des Nutzenden. Danach können Sie ein Brainstorming machen und verschiedene Lösungswege in Betracht ziehen.
  3. Wo liegt das Problem? 
    Diese Frage müssen besonders UX-Designer beantworten können, da das Problem möglicherweise nur in einem bestimmten Bereich auftritt (d. h. in der mobilen App, in der Desktop-Version oder in einem Teil des Produkts). Dieser Schritt ist wichtig, da Sie sich so auf einen bestimmten Bereich konzentrieren können. Wenn das Problem in mehreren Bereichen auftritt, können Sie die Zusammenhänge besser verstehen, in denen eine Lösung erforderlich ist.
  4. Warum? 
    Diese Frage ist von allen vier grundlegenden Fragen vielleicht die wesentlichste. Was würde es Nutzende bedeuten, wenn das Problem gelöst wäre? Welchen Mehrwert gewinnen einzelne Nutzende? Und unternehmensweit gedacht: Wie würde sich die Lösung des Benutzerproblems auf das Geschäft auswirken?

Design Thinking: Best Practices in der Definitionsphase

Ähnlich wie die Fragen, die Sie in der Definitionsphase unterstützen, gibt es auch Best Practices, die Sie in diesem Schritt des Design Thinking befolgen sollten.

Das Point-of-View-(POV)-Statement

Hier fassen Sie Ihre Arbeit in einer einzigen Aussage zusammen. Darin wird festgelegt, wer Ihre Nutzende sind, welche Bedürfnisse sie haben und welche anderen überraschenden Elemente oder Erkenntnisse Sie bei Ihren Nachforschungen gesammelt haben. Dieses Point-of-View-Statement kann einer bestimmten Formel folgen: (Nutzende) muss (Verb), weil (überraschendes Element oder Erkenntnis)

In unserem Autokauf-Szenario könnte die Aussage wie folgt lauten: „Der unentschlossene Autokäufer Brian muss das für ihn perfekte Auto gezeigt bekommen, weil er sich nicht zutraut, einen großen Kauf zu tätigen.“ Das POV-Statement sollte auf einzelne Nutzende bezogen sein.

„Wie könnten wir …?“

Sobald Ihr POV-Statement steht, können Sie bestimmen, wo im Design Möglichkeiten für die Lösung des Benutzerproblems liegen. Analysieren Sie Ihr POV-Statement und sammeln Sie per Brainstorming Themen, die sich aus dem Problem ergeben. Wandeln Sie diese Unterthemen anschließend in eine Frage um, indem Sie „Wie könnten wir“ voranstellen. Wenn wir das obige POV-Statement heranziehen, könnten die „Wie könnten wir“-Fragen so aussehen:

  • Wie könnten wir herausfinden, welches Auto Brian wirklich haben möchte?
  • Wie könnten wir Brians Selbstvertrauen stärken?
  • Wie könnten wir Finanzierungsmöglichkeiten am besten präsentieren?

Über die Frage „Wie könnten wir …?“ sollten Ihnen viele mögliche Lösungen einfallen, einschließlich Lösungen, die ausgefallen oder nicht machbar sind. Es geht hier darum, mehrere Lösungsmöglichkeiten zu sammeln, aus dem Sie dann jene Lösungen auswählen und priorisieren können, die Ihnen besonders sinnvoll erscheinen.

Definitionsphase Bild

Die fünf „Warum“-Fragen

Die Five-Whys-Methode wurde von Toyota entwickelt und dient im Rahmen der Problemlösungsschulung des Unternehmens dazu, die Ursache eines Problems zu finden. Dabei wird eine Frage gestellt und dann bei jeder weiteren Antwort „Warum“ gefragt. Im Beispiel mit Brian könnte dieser Dialog so aussehen:

  1. Warum hat Brian nicht das Selbstvertrauen, um sich für ein neues Auto zu entscheiden? Weil er von den Möglichkeiten überwältigt ist.
  2. Warum ist er von den Möglichkeiten überwältigt? Weil er glaubt, dass er nicht genug über Autos weiß, um die richtige Entscheidung zu treffen.
  3. Warum glaubt er, dass er nicht genug über Autos weiß? Weil er nicht weiß, welche Fragen er dem Autohändler stellen soll.
  4. Warum weiß er nicht, welche Fragen er stellen soll? Weil er nicht weiß, was ihm bei einem Auto am wichtigsten ist.
  5. Warum weiß er nicht, was ihm bei einem Auto am wichtigsten ist? Weil er sich noch nie damit beschäftigen musste.

Die Hauptursache für Brians Mangel an Selbstvertrauen beim Autokauf könnte also sein, dass er nicht weiß, was er wirklich will. Eine mögliche Lösung könnte ein Quiz sein, das in Ihrem Produkt eingebettet ist und das Brian dabei hilft, seine Prioritäten für ein neues Auto zu bestimmen.

Die Laddering-Methode

Diese Methode dient dazu, eine Vielzahl von Benutzerbedürfnissen zu ermitteln und entsprechende Maßnahmen zu entwickeln. Beim Laddering stellt man zuerst eine grundlegende Frage und fragt dann mehrmals „Warum“, bis eine abstrakte Aussage über die Kerngefühle des einzelnen Nutzenden getroffen werden kann. Diese abstrakte Aussage wird dann weiterverfolgt, indem bei jedem Punkt nach dem „Wie“ gefragt wird. Am Ende sollten Sie eine Hierarchie der Benutzerbedürfnisse erhalten, anhand derer Sie eine Vielzahl von Lösungen formulieren können.

Erfahrungsberichte sammeln und analysieren

Indem Sie die User Stories in einer User Story Map analysieren, können Sie besser feststellen, welche Aufgaben und Aktivitäten für Ihre Nutzende am unangenehmsten sind, und dann Lösungen für diese Unannehmlichkeiten formulieren.

Vielleicht wissen Sie, dass sich Brian nur ungern auf Websites einloggt. Dann können Sie Alternativen zum Erstellen eines Passworts und Benutzernamens in Betracht ziehen. Die Visualisierung einer User Story Map hilft Ihnen, zu erkennen, wo Verbesserungsmöglichkeiten liegen.

Projekt Entwicklungsplan
User Story Map Beispiel (Klicken Sie auf das Bild, um es online zu bearbeiten)

Analyse und Synthese

Sobald das zentrale Problem steht, können Sie es in kleinere Teile aufspalten. Finden Sie anschließend eine Lösung für jeden dieser Teile.

Und so einfach ist es – jetzt kennen Sie alle Tools und Best Practices für die Definitionsphase, um herauszufinden, welches Problem Sie eigentlich lösen und warum die Lösung für den Kunden wertvoll ist.

User Story Map

Ermöglichen Sie Ihrem Team noch heute Design Thinking in Lucidspark.

Jetzt testen

Über Lucidspark

Lucidspark, ein Cloud-basiertes virtuelles Whiteboard, ist eine Kernkomponente der visuellen Kooperationssuite von Lucid Software. Auf dieser hochmodernen digitalen Arbeitsfläche können Teams Brainstorming-Sessions durchführen, zusammenarbeiten und gemeinsame Ideen in umsetzbare nächste Schritte umwandeln – alles in Echtzeit. Lucid ist stolz darauf, dass Spitzenunternehmen auf der ganzen Welt seine Produkte nutzen, darunter Kunden wie Google, GE und NBC Universal sowie 99 % der Fortune 500. Lucid arbeitet mit branchenführenden Partnern wie Google, Atlassian und Microsoft zusammen. Seit seiner Gründung wurde Lucid mit zahlreichen Preisen für seine Produkte, Geschäftspraktiken und Unternehmenskultur gewürdigt. Weitere Informationen finden sie unter lucidspark.com.

Verwandte Artikel

  • User Story Mapping von A bis Z

    Erfahren Sie mehr über User Story Mapping – und wie es der Produktentwicklung zur Nutze kommt. 

  • Wie Sie mit Lucidspark eine User Story abbilden

    In diesem Blog-Beitrag erfahren Sie, wie Sie mit Lucidspark schnell, einfach und gemeinsam mit Ihrem gesamten Team eine Story Map entwickeln können.

Start diagramming with Lucidchart today—try it for free!

Kostenlos registrieren

oder weiter mit

Anmelden mit GoogleAnmeldenAnmelden mit MicrosoftAnmeldenAnmelden mit SlackAnmelden

Mit der Registrierung stimmen Sie unseren Nutzungsbedingungen zu und bestätigen, dass Sie unsere Datenschutzrichtlinie gelesen und verstanden haben.

Loslegen

  • Preise
  • Einzelperson
  • Team
  • Unternehmen
  • Vertrieb kontaktieren

Produkt

  • Lucidspark overview
  • Integrationen
  • Sicherheit
  • Lucidchart
DatenschutzRechtlichesCookie-DatenschutzeinstellungenCookie-Richtlinie

© 2024 Lucid Software Inc.