Was vorher fertig sein muss
Mindestens fünf bis acht qualitative Interviews mit echten Nutzern aus der Zielgruppe sind durchgeführt oder fest terminiert.
Die wichtigsten Stakeholder, ein Sponsor mit Entscheidungsmandat und ein Budgetrahmen für Prototypen und Tests sind dokumentiert.
Was vor Start vorliegen muss
Workshop-Raum mit Wandflächen oder Miro-Board mit Phasen-Bahnen; Stickies in fünf Farben; Stifte; Prototyping-Material (Papier, Pappe, Klick-Tool wie Figma); Aufnahme-Setup für Tests; Recruiting-Liste für Nutzertests.
Ein Facilitator für den Gesamtflow; ein bis zwei Researcher für Interviews und Synthese; zwei bis vier Designer und Engineers; ein Sponsor mit Entscheidungsmandat (mindestens an Phasenübergängen); Testnutzer für Phase 5.
Problembereich als ein Absatz, nicht als Lösungsidee; Zielgruppe und Zugang dazu; bekannte Constraints (Budget, Compliance, Technologie); vorherige Lösungsversuche und warum sie scheiterten.
5 Tage Sprint oder 4-8 Wochen iterativ
Phasen-Bahnen an die Wand: Empathize, Define, Ideate, Prototype, Test. Sponsor-Reviews zwischen jeder Phase fest terminieren. Recruiting für Phase 5 in Phase 1 starten, nicht später.
Die eine Frage, die diese Methode beantwortet
Welches reale Nutzerproblem ist es wert, gelöst zu werden, und welche Lösungsidee überlebt einen Test mit echten Nutzern?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Empathize | 3-10 Tage | 5-10 Interviews und 2-3 Beobachtungen im Kontext durchführen. Notizen, Zitate, beobachtete Workarounds und emotionale Reaktionen sammeln. Keine Lösungsfragen stellen. | Wenn Interviewfragen mit „Würden Sie X nutzen“ beginnen, produziert die Phase nur Höflichkeitsdaten. Auf vergangene Verhaltensweisen fragen, nicht auf hypothetische. |
2Phase 2: Define | 0,5-1 Tag | Patterns clustern. Eine Point-of-View-Aussage formulieren: Nutzer X braucht Y, weil Z (Insight). Anschließend 3-5 How-Might-We-Fragen ableiten und die wichtigste auswählen. | Wenn die POV-Aussage eine Lösung enthält („braucht eine App“), neu formulieren. Z (Insight) muss überraschend oder kontraintuitiv sein, sonst war Empathize zu oberflächlich. |
3Phase 3: Ideate | 0,5-1 Tag | Crazy 8s, Brainwriting oder Worst Possible Idea zur HMW-Frage. Mindestens 40 Ideen, dann Clustern und 2-3 Konzepte zur Prototyping-Auswahl. | Wenn die Gruppe nach 20 Ideen aufhört, fehlt Divergenz. Erzwinge mindestens eine Runde mit absurden oder konträren Ideen, sonst landet die Gruppe bei der ersten naheliegenden Lösung. |
4Phase 4: Prototype | 1-5 Tage | Low-Fidelity-Prototyp bauen, der genau die zentrale Frage testbar macht. Papier, Klickdummy oder Wizard-of-Oz, kein produktiver Code. Pro Konzept einen Prototyp. | Realistisch wirken schlägt vollständig. Prototyp ist eine Frage, keine Antwort. Wer Backend-Logik baut, hat die Phase verlassen und arbeitet bereits an der Lösung. |
5Phase 5: Test | 1-3 Tage | 5-8 moderierte 1:1-Tests pro Prototyp. Beobachten, was Nutzer tun, nicht was sie sagen. Patterns nach Test 5 synthetisieren. Entscheidung: weiter, pivotieren oder verwerfen. | Pattern-Erkennung beginnt nach Test 5, nicht nach Test 2. Beobachtungs-Raster pro Test strikt befüllen. Bei Widerspruch zwischen Verhalten und Aussage zählt das Verhalten. |
Was am Ende rauskommt
Strukturierte Doku mit Research-Notizen, geclusterten Insights, POV-Aussage, gewählter HMW-Frage, Ideation-Outputs, Prototyp-Links, Test-Protokollen pro Nutzer, Patterns und finaler Entscheidung mit Owner und Folgeaktion.
Pro Iteration ein eigener Ordner mit Datum und Problemraum als Titel. Vorherige Iterationen archivieren, nicht überschreiben. Entscheidungen zwischen Phasen mit Datum und Sponsor-Freigabe dokumentieren.
Kompakte Arbeitsvorlage für Design Thinking mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Design Thinking Arbeitsvorlage
## Ziel
Iterativer Ansatz, der Nutzerverständnis, Problemframing, Ideation, Prototyping und Testen verbindet.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- Problem Statement:
- Prototype:
- Test Learnings:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## Design Thinking — Selbständige Steuerberatung, Mandantenkommunikation (Q2 2026)
**Empathize**: 7 Interviews mit Solo-Steuerberaterinnen, 2 Tage Schatten-Beobachtung in der Kanzlei von Sabine. 12 Workarounds dokumentiert (Whatsapp für Unterlagen, Excel-Listen für Rückfragen).
**POV**: Sabine, Solo-Steuerberaterin mit 80 Mandanten, braucht eine Möglichkeit, eingehende Unterlagen nach Mandant zuzuordnen, weil sie jede Mail manuell sortiert und dabei 6 h pro Woche verliert.
**HMW**: Wie könnten wir Unterlagen automatisch dem richtigen Mandanten zuordnen, ohne dass Mandanten ihr Verhalten ändern?
**Ideation**: 47 Ideen, 3 Konzepte zur Prototyping-Auswahl: (1) E-Mail-Forwarding mit Tag-Erkennung, (2) Mandanten-Upload-Portal, (3) Whatsapp-Bot.
**Prototyp**: Klickdummy für Konzept 1 (Figma, 9 Screens) plus Wizard-of-Oz-Setup, in dem Researcher manuell Tags verteilen.
**Test**: 6 Steuerberaterinnen, je 60 min. 5/6 verstanden das Konzept sofort, 4/6 wollten es heute nutzen, 2/6 hatten Sorgen um Mandantengeheimnis bei der KI-Tag-Erkennung.
**Entscheidung (Sponsor: @marcus, 18.05.2026)**: Konzept 1 weiterverfolgen, mit explizitem Opt-in pro Mandant. Implementierungs-Spike 2 Wochen, danach Pilot mit 5 Beraterinnen.Symptome erkennen, gegensteuern
Team startet mit Lösungsideen, Interviews werden „später nachgeholt“ oder durch interne Annahmen ersetzt.
Phase 1 als harte Voraussetzung für Phase 2 setzen. Ohne mindestens fünf Interviews keine POV-Formulierung. Sponsor muss diese Regel mittragen.
Define-Phase endet mit „Nutzer braucht eine mobile App“ statt mit einem Bedürfnis.
POV-Template strikt: Wer, braucht was, weil welcher überraschende Insight. Lösungsbestandteile werden gestrichen und in den HMW oder die Ideation verschoben.
Gruppe wählt nach 15 min die naheliegende Lösung, weil sie „offensichtlich gut“ wirkt.
Mindestens 40 Ideen erzwingen, davon mindestens 5 absurde. Erst danach Konvergenz. Dot-Voting nach voller Divergenz, nicht währenddessen.
Phase 4 läuft 4 Wochen statt 4 Tage, Engineering baut Backend, weil „wir es eh brauchen“.
Fidelity-Regel: nur so viel bauen, wie die zentrale Testfrage verlangt. Klickdummy oder Wizard-of-Oz vor Code. Wer Backend baut, hat Phase 4 verlassen.
Phase 5 mit Kollegen, Freunden oder bestehenden Power-Usern besetzt, Feedback ist verzerrt.
Recruiting-Kriterien in Phase 1 definieren und in Phase 5 strikt halten. Externe Recruiter als Backup. Lieber Phase verschieben als mit falschen Nutzern testen.
Team läuft Phase 1-5 einmal durch und betrachtet das Ergebnis als final, ohne Rückkehr in frühere Phasen.
Nach Phase 5 explizit fragen: zurück zu Define, Ideate oder Prototype, oder weiter zur Umsetzung. Iteration ist die Norm, lineare Durchläufe sind die Ausnahme.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.