Phase: Verstehen Tauche ein in die Welt deiner Nutzer

Bevor du eine Lösung entwickelst, musst du sicher sein, dass du das richtige Problem löst. Die Verstehen-Phase ist der Startpunkt jedes Design-Thinking-Prozesses: Hier klärst du den Kontext, identifizierst Stakeholder und formulierst eine Herausforderung, die das Team in den folgenden Phasen bearbeitet.

Verstehen auf einen Blick

Phase
1 von 6 im Design-Thinking-Prozess
Ziel
Das richtige Problem identifizieren und eingrenzen
Methoden
Desk Research, Stakeholder-Mapping, Problemdefinition
Dauer
Typisch 2-4 Stunden im Workshop

Warum ist die Verstehen-Phase so entscheidend?

Die meisten gescheiterten Projekte scheitern nicht an schlechten Lösungen — sie scheitern daran, dass die falsche Frage beantwortet wurde. Ein Unternehmen baut eine App, die niemand braucht. Ein Team optimiert einen Prozess, der das eigentliche Problem gar nicht verursacht. Die Verstehen-Phase schützt dich davor.

Hier investierst du Zeit, um den Problemraum zu erkunden: Wer ist betroffen? Was wissen wir bereits? Was nehmen wir nur an? Welche Rahmenbedingungen gibt es? Am Ende steht eine klare, fokussierte Problemstellung — keine vage Idee, sondern ein konkreter Satz, der das Team in die richtige Richtung lenkt.

Vages Problem Verstehen-Phase Fokussierte Fragestellung

Welche Methoden helfen beim Verstehen?

Drei Werkzeuge haben sich bewährt:

  • Desk Research: Sammle alles, was bereits bekannt ist — Studien, Kundenfeedback, Support-Tickets, Marktdaten. Ziel ist nicht Vollständigkeit, sondern ein gemeinsames Wissensfundament im Team.
  • Stakeholder-Mapping: Wer ist vom Problem betroffen? Wer hat Einfluss? Wer hat wertvolles Wissen? Zeichne eine Karte aller Beteiligten und ihrer Beziehungen zueinander.
  • Problemdefinition (Point of View): Formuliere das Problem als konkreten Satz: „[Nutzer] braucht [Bedürfnis], weil [Erkenntnis]." Diese Formel zwingt dich, spezifisch zu werden.

Welche Fehler passieren am häufigsten?

Der häufigste Fehler: Zu schnell in den Lösungsmodus wechseln. Jemand sagt „Wir brauchen eine App!" — und schon diskutiert das Team Features statt Probleme. Stopp. In der Verstehen-Phase sind Lösungsideen tabu.

Zweiter Fehler: Annahmen als Fakten behandeln. „Unsere Kunden wollen das bestimmt" ist keine Erkenntnis, sondern eine Hypothese. Schreib sie auf, markiere sie als Annahme und plane, sie in der Beobachtungsphase zu überprüfen.

Dritter Fehler: Zu breit bleiben. „Wir wollen die Kundenzufriedenheit verbessern" ist kein gutes Problem — es ist ein Wunsch. Grenz es ein: Welche Kunden? In welcher Situation? Bei welchem Schritt im Prozess?