Was vorher fertig sein muss
Ein grober Problemraum oder ein Ausgangs-Brief mit Stakeholder-Erwartungen und Constraints liegt vor, an dem die Discover-Phase ansetzt.
Was vor Start vorliegen muss
Projektplan mit vier Phasen-Slots (Discover, Define, Develop, Deliver); Research-Toolkit (Interview-Leitfaden, Templates, Recorder); Synthese-Wand oder Miro-Board; Prototyping-Tools; Tracking-Tool für Erkenntnisse und Entscheidungen.
Ein Lead-Designer oder Service Designer; ein bis drei Researcher; cross-funktionales Kernteam (PM, Engineering, Design); Stakeholder pro Diamant-Übergang als Reviewer; Sponsor mit Mandat zwischen Diamanten.
Ausgangs-Brief; Stakeholder-Map; bekannte Constraints (Zeit, Budget, Tech); Forschungsfragen; vorhandene Daten und Vorarbeiten; gewünschtes Deliverable am Phasen-Ende.
Wochen bis Monate
Phasen visuell als Diamanten an Wand oder Board. Pro Phase Definition Done (was muss am Übergang stehen). Übergänge mit Stakeholder-Reviews terminiert. Synthese-Räume vorbereitet.
Die eine Frage, die diese Methode beantwortet
Welches gerahmte Problem und welche umgesetzte Lösung liefert das Team durch bewusste Divergenz und Konvergenz in zwei Diamanten?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Discover (Diamant 1, Divergenz) | 2-6 Wochen | Problemraum breit erkunden: Nutzerinterviews, Beobachtung, Desk Research, Stakeholder-Interviews, Datenanalyse. Mindestens 10 Datenpunkte aus verschiedenen Quellen. Annahmen sichtbar markieren. | Wer in Discover schon Lösungen denkt, verzerrt Research. Striktes Outcome: Liste an Insights, Themen, offenen Fragen. Keine Lösungsdiskussion zulassen. |
2Phase 2: Define (Diamant 1, Konvergenz) | 1-3 Wochen | Insights clustern, priorisieren, Kern-Problem formulieren. Problem Statement als ein bis zwei Sätze. Decider übergibt von Discover zu Develop mit klarer Problemrahmung. Out-of-Scope explizit benennen. | Wenn Problem Statement vage bleibt („Kunden sind unzufrieden“), war Konvergenz halbherzig. Pro Statement Quelle, Reichweite und Wirkung dokumentieren. |
3Phase 3: Develop (Diamant 2, Divergenz) | 2-6 Wochen | Lösungsraum breit erkunden: Ideation-Workshops, Sketching, Prototyping, Service-Blueprints. Mehrere Lösungsoptionen parallel. Mit Nutzern testen, früh und billig. | Wer in Develop nur eine Lösung verfolgt, verfehlt den Sinn der Divergenz. Mindestens drei Optionen sind Pflicht, mit Pro/Contra dokumentiert. |
4Phase 4: Deliver (Diamant 2, Konvergenz) | Wochen bis Monate | Beste Lösung implementieren, ausrollen, lernen. Akzeptanzkriterien aus Define ableiten. Erfolgsmessung gegen Problem Statement. Iteratives Refinement durch Feedback nach Launch. | Deliver ohne Erfolgsmessung gegen Define ist Output statt Outcome. Wenn niemand prüft, ob das Problem aus Phase 2 gelöst wurde, schließt sich der Kreis nie. |
5Phase 5: Übergänge zwischen Diamanten | Halber bis ein Tag pro Übergang | Vor jedem Diamant-Übergang Synthese-Workshop mit Stakeholdern. Schriftlicher Entscheidungspunkt: was bekannt, was unsicher, was als nächstes. Decider signiert. | Ohne dokumentierte Übergänge verschwimmen die Diamanten zu einem Strom. Synthese ist Pflicht-Artefakt, sonst kann später niemand rekonstruieren, was wann entschieden wurde. |
Was am Ende rauskommt
Pro Phase Deliverable: Discover-Insights-Report, Problem Statement (Define), Lösungsoptionen mit Prototypen (Develop), implementierte Lösung mit Erfolgsmessung (Deliver). Plus Übergangs-Dokumente zwischen Diamanten und finaler Outcome-Report.
Projektordner mit Phasen-Unterordnern. Pro Übergang versioniertes Synthese-Dokument mit Datum und Decider. Spätere Iterationen erzeugen neue Diamant-Runden mit Verweis auf Vorrunde.
Kompakte Arbeitsvorlage für Double Diamond mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Double Diamond Arbeitsvorlage
## Ziel
Vier-Phasen-Designprozess von Discover, Define, Develop, Deliver mit zwei Divergenz-Konvergenz-Diamanten.
## 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:
- Lösungsoptionen:
- Prototypen:
- Deliverables je Phase:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## Double Diamond — Antrags-Erlebnis Wohngeld Kommunalverwaltung Musterstadt (Mai 2026)
**Discover (3 Wochen)**: 18 Nutzerinterviews, 6 Mitarbeiter-Shadowings, Datenanalyse Antragsdurchlaufzeiten. Insights: 73% der Anträge fehlen Unterlagen, mittlere Bearbeitungszeit 47 Tage, Hotline-Anrufe vor Antragsabgabe selten genutzt.
**Define (1 Woche)**: Problem Statement: „Antragstellende verstehen nicht vorab, welche Unterlagen sie zusammen mit dem Hauptantrag einreichen müssen, daher entstehen Rückfragen und Bearbeitungszeit verdoppelt sich.“ Out-of-Scope: Antragsformular selbst (regulatorisch fix).
**Develop (4 Wochen)**: Drei Optionen prototypisiert: (A) interaktive Checkliste vor Antrag, (B) Pre-Submit-Vollständigkeitsprüfung im Formular, (C) Termin-Buchungs-Assistent mit Vorab-Liste. Test mit 12 Nutzern. Option B liefert in Test 89% vollständige Anträge gegen 41% Baseline.
**Deliver (8 Wochen)**: Option B implementiert, Rollout Pilot zwei Stadtbezirke ab 01.07. Erfolgsmessung: Anteil vollständige Anträge, Bearbeitungszeit-Median. Nach 90 Tagen Review.
**Übergänge**: Define-Übergang @sabine (Amtsleitung) signiert 15.04. Deliver-Übergang @marcus (IT-Leitung) signiert 12.05.Symptome erkennen, gegensteuern
Interviews leitend gefragt („wäre eine App hilfreich?“), Lösungsraum vorzeitig fixiert.
Interview-Leitfaden auf Probleme und Verhalten richten, nicht Lösungen. Wer in Discover „Feature X wäre gut“ produziert, muss zurück.
Aus Discover wird direkt prototypisiert, Problem Statement fehlt oder bleibt vage.
Define als Pflicht-Phase mit Decider-Signature. Ohne Problem Statement kein Develop. Frage zur Validierung: kann ich Lösung gegen Problem messen?
Eine Lösung wird sofort verfolgt, keine Alternativen, kein Vergleich.
Pflicht: mindestens drei Optionen mit Pro/Contra. Wer nur eine Lösung hat, ist in der falschen Phase. Lieber Alternativen erfinden als überspringen.
Lösung wird ausgerollt, niemand misst, ob das Problem aus Define gelöst wurde.
Erfolgsmessung in Define festlegen, in Deliver erheben. Schließen des Kreises ist Pflicht, sonst Outcome unbekannt.
Phasen laufen parallel, niemand kann sagen, wo das Projekt steht.
Phasen visuell sichtbar an Wand oder Board. Übergänge als Termine mit Decider. Wenn Iteration nötig, ehrlich rückspringen, nicht alles gleichzeitig.
Stakeholder erfahren erst in Deliver, was entschieden wurde, blockieren spät.
Stakeholder in jedem Übergang einbinden, Reviews terminieren. Spätes Veto-Risiko wird durch frühe Beteiligung kleiner.
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.