Katalog
method#Produkt#Lieferung#Governance#Softwareentwicklung

Double Diamond

Ein vierphasiges Designframework (Discover, Define, Develop, Deliver) zur strukturierten Problemerkennung und Lösungserarbeitung.

Das Double Diamond ist eine strukturierte Vier-Phasen-Designmethode (Discover, Define, Develop, Deliver), die Teams von der Problemanalyse bis zur validierten Lösung führt.
Etabliert
Mittel

Klassifikation

  • Mittel
  • Organisatorisch
  • Organisation
  • Fortgeschritten

Technischer Kontext

Produktmanagement-Tools (Roadmaps, Backlogs)Analytics- und User-Research-PlattformenPrototyping- und Usability-Test-Tools

Prinzipien & Ziele

Trennung von divergenten und konvergenten PhasenNutzerzentrierung und EvidenzbasierungFrühe Validierung vor großvolumiger Umsetzung
Erkundung
Unternehmen, Domäne, Team

Use Cases & Szenarien

Kompromisse

  • Unvollständige Nutzerrecherche führt zu falschen Annahmen
  • Stakeholder-Überforderung durch zu viele Divergenz-Optionen
  • Überspringen von Validierungs-Schritten erhöht Implementierungsrisiko
  • Frühzeitige Einbindung von Stakeholdern und Entscheidungsträgern
  • Klare Abbruchkriterien für Experimente definieren
  • Regelmäßiges Dokumentieren von Erkenntnissen und Entscheidungen

I/O & Ressourcen

  • Zugriff auf Nutzerdaten und Analytics
  • Interdisziplinäre Teammitglieder
  • Stakeholder-Unterstützung und Zeit
  • Validated Problem Statements
  • Prototypen und Testresultate
  • Entscheidungsgrundlagen für Umsetzung

Beschreibung

Das Double Diamond ist eine strukturierte Vier-Phasen-Designmethode (Discover, Define, Develop, Deliver), die Teams von der Problemanalyse bis zur validierten Lösung führt. Sie trennt divergentes und konvergentes Denken, reduziert Risiko und schafft Klarheit. Häufig in der Produktentwicklung genutzt, fördert sie Stakeholder-Alignment und iteratives Lernen.

  • Reduziert Risiko durch stufenweise Validierung
  • Verbessert Stakeholder-Alignment
  • Ermöglicht fokussiertes Prototyping und Lernen

  • Kann linear missverstanden werden, obwohl iterativ gedacht
  • Benötigt Zeit und Ressourcen für gründliche Discover-Phase
  • Weniger geeignet für rein technische Refaktorierungen ohne Nutzerfokus

  • Zeit bis zu validiertem Lernen

    Misst die Zeit vom Start der Discover-Phase bis zur validierten Hypothese.

  • Anzahl getesteter Hypothesen

    Zählt validierte und verworfene Hypothesen in einem Zyklus.

  • Konversionsrate von Prototypen zu Releases

    Verhältnis der Prototypen, die zu produktiven Releases führen.

Design Council Fallstudie

Beschreibung der Anwendung des Double Diamond in öffentlichen Projekten zur Nutzerzentrierten Gestaltung.

Produktentwicklung bei Mittelstandssoftware

Anwendung des Modells zur schnellen Validierung von Kundenbedarf vor Entwicklung.

Innovationsworkshop einer Bank

Workshopreihe, die Discovery-Phasen zur Identifikation neuer Serviceangebote nutzt.

1

Einrichten eines interdisziplinären Kernteams und Sponsorenabstimmung.

2

Durchführung fokussierter Discover-Aktivitäten: Interviews, Datenanalyse, Beobachtung.

3

Define-Workshops zur Synthese und Priorisierung von Erkenntnissen.

4

Develop-Iterationen mit Prototypen und Nutzertests.

5

Deliver-Pilotierung, Monitoring und Skalierung erfolgreicher Lösungen.

⚠️ Technische Schulden & Engpässe

  • Prototypen werden in Produktion übernommen ohne Refactoring
  • Unzureichend dokumentierte Research-Ergebnisse erschweren spätere Entscheidungen
  • Veraltete Annahmen verbleiben im Backlog ohne Überprüfung
Begrenzte Research-RessourcenEntscheidungsprozesse der StakeholderTechnische Integrationsrestriktionen
  • Double Diamond nur als Phasen-Checkliste nutzen ohne Iteration
  • Nur oberflächliche Research-Aktivitäten als Discover deklarieren
  • Konvergenz erzwingen bevor valide Daten vorliegen
  • Falsche Erwartung, dass Modell immer linear abläuft
  • Zu frühe Ressourcenbindung für Umsetzung ohne Validierung
  • Unklare Erfolgskriterien vor Beginn der Phasen
Moderation und Workshop-FacilitationNutzerforschung und InterviewtechnikSchnelles Prototyping und Testing
Nutzerzentrierung bei LösungsentwicklungSchnelle Validierung zur RisikoreduktionCross-funktionale Zusammenarbeit
  • Zeitliche Begrenzungen für ausführliche Discovery
  • Budgetrestriktionen für Prototyping
  • Organisatorische Silos verhindern Cross-funktionalität