Double Diamond Design Framework für physische Produkte

Das Double Diamond Design Framework ist ein leistungsfähiges Instrument zur Strukturierung von Innovation, aber in seiner Standardform reicht es für physische Produkte oft nicht aus. Der Schwerpunkt liegt auf digitalen Diensten und Nutzerwünschen. Wer ein greifbares Produkt auf den Markt bringen will, stellt schnell fest, dass Wünschbarkeit allein keinen Erfolg garantiert: Ohne frühzeitige Validierung von Technik, Stückkosten und Fertigbarkeit bleibt eine gute Idee nur eine Absichtserklärung.

Dieser Artikel erklärt, wie Sie das Modell auf Hardware und Kunststoffprodukte zuschneiden, damit Sie nicht erst in der Entwicklungsphase entdecken, dass das Fundament brüchig ist.

Was bedeutet das Double Diamond Modell in der Praxis?

Das Double Diamond Design Framework gliedert Innovation in vier Phasen, die abwechselnd divergieren und konvergieren: Discover, Define, Develop und Deliver. In der ersten Diamantform erkunden Sie das Problemfeld breit. Anschließend definieren Sie präzise, was genau gelöst werden soll; die zweite Diamantform wiederholt dann dasselbe Muster für Entwurf und Realisierung der Lösung.

Diese Methode zwingt Teams, nicht sofort in Lösungsvorschläge zu springen, sondern zuerst Gewissheit über die Problemstellung zu schaffen.

Bei digitalen Anwendungen funktioniert das hervorragend, denn Iterationen sind günstig und Feedbackzyklen kurz. Bei der Entwicklung physischer Produkte erfordert jede Phase jedoch zusätzliche Disziplin hinsichtlich technischer und finanzieller Rahmenbedingungen. Die Standarddarstellung des Double Diamond Design Frameworks fokussiert meist auf Dienstleistungen oder Software, wo Annahmen schnell mit kostengünstigen Prototypen getestet werden können.

Für Hersteller physischer Güter besteht dieser Luxus nicht.

Deshalb müssen Sie von Tag eins an Einschränkungen berücksichtigen, die in einem digitalen Prozess erst viel später relevant werden: Materialkunde, Montagefolge, Zertifizierungsprozesse. Ohne diese Anpassung bleiben Sie nach einer perfekten Discover-Phase in der Engineering-Phase stecken.

Warum zuerst das Problem validieren und erst dann die Lösung?

Die strikte Trennung von Problem- und Lösungsraum verhindert, dass Organisationen in Produkte investieren, für die es keinen realen Marktbedarf gibt. Das kann bei physischer Innovation verheerend sein wegen hoher Entwicklungskosten und langer Durchlaufzeiten. Ein validierter Kundeneinblick ist etwas grundlegend anderes als eine Annahme: Er basiert auf Belegen aus der Praxis, nicht auf internen Überzeugungen oder vermuteten Wünschen von Stakeholdern.

Viele Produktteams starten unbewusst dennoch aus einer Lösung heraus.

Sie haben ein technisches Konzept oder ein ästhetisches Vorbild und suchen anschließend ein Problem dazu. Das erzeugt zwar raffinierte Produkte, die aber niemand wirklich braucht. Innerhalb der Define-Phase des Double Diamond Design Frameworks bedeutet Validierung, dass Sie Unsicherheiten mit Daten und Gesprächen ausräumen, nicht mit Brainstorming-Sessions oder Management-Gefühlsempfindungen.

Erst wenn das Problem klar definiert und von der Zielgruppe bestätigt ist, dürfen Sie in den Lösungsraum eintreten.

Diese Disziplin mag sich manchmal wie Verzögerung anfühlen, ist aber die einzige Möglichkeit, spätere, deutlich teurere Fehlkosten zu vermeiden. Bei physischen Produkten lassen sich Fehler in der Problemdefinition nicht mit einem Update oder Patch beheben; man muss zurück an den Zeichentisch und Werkzeuge neu fertigen.

Warum das Standardmodell bei physischen Produkten nicht ausreicht

Desirability ist notwendig, aber für Hardware niemals ausreichend: Ein gewünschtes Produkt, das nicht produzierbar oder bezahlbar ist, existiert kommerziell nicht. Das Standard-Double-Diamond-Design-Framework behandelt technische Machbarkeit, Kostenkalkulation, Zertifizierungsanforderungen und Produktionskapazitäten oft als spätere Themen, obwohl sie bei physischer Innovation genauso wichtig sind wie Nutzerwünsche.

Ein brillantes Design scheitert, wenn die Formbzw. Matrize nicht herstellbar ist.

Berücksichtigen Sie diese harten Randbedingungen erst in der Develop-Phase, dann stoßen Sie auf Probleme zu einem Zeitpunkt, an dem Änderungen extrem teuer geworden sind. Man wählt nicht einfach ein anderes Material oder passt eine Toleranz an, ohne Auswirkungen auf die gesamte Kette von Zulieferer bis Endmontage zu haben.

Deshalb müssen technische und finanzielle Anforderungen gleichberechtigte Partner in der Definitionsphase sein.

PEZY bringt in der Define-Phase technisches, finanzielles und Produktionswissen in den Innovationsprozess ein, um die Lücke zwischen Idee und Herstellbarkeit zu schließen. So wissen Sie nicht nur, was der Kunde will, sondern auch, was es kosten darf, welche Zertifizierungen erforderlich sind und ob die kritische Funktion technisch überhaupt innerhalb der gesetzten Rahmen realisierbar ist.

Ohne diese Integration bleibt Ihr erster Diamant eine Übung im Wunschdenken.

Technische und finanzielle Randbedingungen in Define integrieren

Bevor Sie mit der Entwicklung beginnen, muss glasklar sein, ob die kritische Funktion technisch funktioniert, was das Produkt maximal kosten darf und welche Investition in Werkzeuge und Zertifizierungen realistisch in die Business-Case passt. Diese Fragen wirken während der Problemuntersuchung vorzeitig, sind aber genau der Filter, der zwischen einer netten Idee und einem tragfähigen Produkt unterscheidet.

Eine gute Idee ist noch keine Produktentscheidung.

Für physische Produkte muss zuerst klar sein, ob die kritische Funktion technisch funktionieren kann und was das Produkt kosten darf, bevor Sie weiter in die Detaillierung investieren. In der Define-Phase müssen Sie deshalb bereits technische Machbarkeit validieren durch gezielte Tests, nicht durch theoretische Studien oder Versprechungen von Lieferanten.

Fertigbarkeit ist kein abstrakter Begriff, sondern eine rechnerische Realität.

Indem Sie frühzeitig Design for Manufacturing-Prinzipien anwenden, verhindern Sie, dass Sie ein Design definieren, das zwar dem Nutzerwunsch entspricht, aber nicht zu den erforderlichen Kosten produziert werden kann. Zertifizierungsanforderungen gehören ebenfalls hierher: Eine CE-Kennzeichnung oder medizinische Zulassung bestimmt oft die Produktarchitektur und die Materialwahl.

Wenn Sie dies nicht in Ihrer Definition berücksichtigen, bauen Sie zwangsläufig ein Produkt, das später die Prüfung nicht besteht.

Kritische Funktionen und Kostenpreis als harte Anforderungen

Der Stückpreis ist kein Ergebnis des Designprozesses, sondern eine Bedingung, die Sie in die Problemdefinition aufnehmen — ebenso wie die technischen Leistungswerte, die das Produkt mindestens liefern muss. Wenn Sie erst nach der Detaillierung rechnen, werden Sie oft enttäuscht und müssen Kompromisse bei Funktionalität oder Qualität eingehen, die Sie in der Discover-Phase versprochen haben.

Legt die Kostenzielvorgabe daher als Teil Ihres Product Decision Pack fest.

Zertifizierung und Produktionskapazität frühzeitig sichern

Zertifizierungsprozesse dauern Monate und erfordern spezifische Testaufbauten. Daher müssen Sie die Anforderungen kennen, bevor Sie das Produkt gestalten, nicht erst, wenn der Prototyp zur Validierung bereitsteht. Dasselbe gilt für Produktionskapazitäten: Wenn Sie Seriengrößen oder Zykluszeiten nicht kennen, können Sie keine verlässliche Business-Case aufstellen.

Dieses Wissen gehört in den ersten Diamanten.

Vom ersten Diamanten zur vollständigen Produktentscheidung

Der Übergang von abstrakten Erkenntnissen zu konkretem Engineering erfordert ein Dokument, das als Brücke zwischen Design Thinking und technischer Umsetzung fungiert, damit spätere Phasen nicht an unerwarteten Hindernissen scheitern. Das Product Decision Pack bildet das konkrete Ergebnis von PEZY Define und enthält die Validierungen, die nötig sind, um verantwortungsvoll in die Entwicklung zu starten, einschließlich Antworten auf Fragen zu Technik, Kosten und Regulierung.

Dieses Paket ist mehr als eine Spezifikationsliste.

Es ist der Nachweis, dass Ihre Problemdefinition robust genug ist, um die Investition in die Develop-Phase zu rechtfertigen. Beim Erstellen der Produktspezifikation übersetzen Sie Nutzeranforderungen in technische Parameter, die an Fertigbarkeit und Kosten geprüft wurden, sodass Ingenieure nicht über die Intention hinter den Anforderungen raten müssen.

Ohne dieses Fundament ist jeder Entwicklungsstart ein Glücksspiel.

Viele Organisationen überspringen diesen Schritt, weil sie glauben, dass ihre Discover-Ergebnisse ausreichend sind; dann fehlt ihnen jedoch die entscheidende Ebene technischer und finanzieller Validierung. Ein PEZY Define-Projekt liefert genau diese fehlende Verbindung, sodass Sie die zweite Diamantform mit Vertrauen betreten können.

Das Product Decision Pack als Fundament

Dieses Dokument bündelt alle Validierungen, Risikoanalysen und Randbedingungen, die nötig sind, um die Develop-Phase zu starten, ohne dass das Team später wegen übersehener Anforderungen zum Zeichentisch zurückkehren muss. Es zwingt das Team, Unschärfen zu beseitigen und explizite Entscheidungen darüber zu treffen, was in Scope ist und was nicht.

Checkliste: Bereit für die Develop-Phase

Sie sind erst zur Entwicklung bereit, wenn die kritische Funktion nachgewiesen ist, die Stückkosten belegt sind, der Zertifizierungsweg bekannt ist und der Produktionspartner in die Spezifikationen eingebunden ist. Fehlt eines dieser Elemente, ist Ihre Produktentscheidung verfrüht und Sie gehen ein unnötiges finanzielles Risiko ein.

Nutzen Sie diese Kriterien als Torwächter.

Die Rolle von Prototyping und TRL im Double Diamond Prozess

Theorie und Praxis treffen in gezielten Validierungsmomenten aufeinander, die speziell darauf ausgerichtet sind, technische Unsicherheiten zu beseitigen, bevor Sie die volle Entwicklungskapazität einsetzen. Während digitale Teams mit klickbaren Prototypen arbeiten, müssen Sie bei physischen Produkten greifbaren Nachweis liefern, dass die gewählte Technologie unter realen Bedingungen funktioniert und nicht nur in einer Laboranordnung.

Das erfordert einen anderen Ansatz für Prototyping.

Ein Proof of Concept ist in diesem Kontext kein grobes Modell zur Visualisierung einer Idee, sondern ein gezieltes Experiment, das die wichtigste technische Risikoannahme aus Ihrer Definition beantwortet. Wenn Sie dies mit der Technology Readiness Level-Skala koppeln, machen Sie technologische Reife messbar und vergleichbar — entscheidend für Investitionsentscheidungen.

So vermeiden Sie, dass Sie auf Basis von Hoffnung entwickeln.

Proof of Concept als Validierungsmeilenstein

Ein PoC testet ausschließlich die kritische Funktion oder das größte technische Risiko und hat keinen ästhetischen oder ergonomischen Anspruch, denn das Ziel ist reine Risikoreduktion, nicht Präsentation. Scheitert der PoC, dann ist das ein Versagen in der Define-Phase, nicht in der Entwicklung — und genau das ist die Intention des Double Diamond Design Frameworks für physische Produkte.

Fehlschläge hier sind Gewinne.

Technology Readiness Level als Maßstab

Die TRL-Skala bietet einen objektiven Rahmen, um zu beurteilen, ob eine Technologie reif genug für die Integration in ein Produkt ist; Diskussionen über „Machbarkeit“ weichen standardisierten Bewertungen. Das hilft R&D-Leads und Produktmanagern, Fortschritte zu berichten und Entscheidungszeitpunkte an tatsächliche Reife zu koppeln, statt an Planungsoptimismus.

Wann ist Ihr Produkt wirklich bereit für die Develop-Phase?

Ihr Produkt ist erst dann bereit für die Develop-Phase, wenn Sie neben einem validierten Kundenproblem auch über einen technischen Machbarkeitsnachweis, eine fundierte Kostenkalkulation und einen klaren Weg zu Zertifizierung und Serienproduktion verfügen. Das Double Diamond Design Framework liefert diese Sicherheit nicht automatisch; Sie müssen das Modell aktiv um ingenieurwissenschaftliche und betriebswirtschaftliche Validierungen ergänzen, um Enttäuschungen in späteren Phasen zu vermeiden.

Fehlt diese Sicherheit, ist das Weitermachen unverantwortlich.

Nutzen Sie die erwähnte Checkliste als harte Gate-Kriterium und seien Sie bereit, in die Define-Phase zurückzugehen, wenn Lücken in Ihrer Begründung bestehen. Für Organisationen, die diese Sicherheit suchen, aber nicht über die breite Expertise verfügen, ist ein spezialisiertes Programm häufig der schnellste Weg zu einer validen Produktentscheidung.

Herstellbare Innovation beginnt mit einer ehrlichen Definition.

Häufig gestellte Fragen zum Double Diamond für physische Produkte

Worin unterscheidet sich das Double Diamond Modell für physische Produkte von der Standard-Design-Thinking-Methodik?

Bei physischen Produkten gewichten Sie technische Machbarkeit, Kosten und Fertigbarkeit bereits in der ersten Diamantform als gleichwertige Faktoren neben Nutzerwünschen. Standard-Design-Thinking fokussiert oft primär auf Desirability und verschiebt technische Validierung in die Entwicklungsphase, was bei Hardware zu kostspieligen späten Änderungen führt.

Welche Kriterien müssen validiert sein, bevor ein physisches Produkt in die Develop-Phase geht?

Die kritische Funktion muss technisch durch einen Proof of Concept nachgewiesen sein, die maximale Stückkosten müssen belegt sein und der Zertifizierungsweg muss bekannt sein. Es muss auch klar sein, ob die angestrebte Produktionskapazität und Investition realistisch in den Business Case passen.

Worin besteht der Unterschied zwischen einem validierten Kundeneinblick und einer Annahme in der Define-Phase?

Ein validierter Einblick basiert auf empirischen Belegen wie Nutzertests oder Marktforschung, während eine Annahme auf internen Überzeugungen oder ungeprüften Hypothesen beruht. Bei physischen Produkten ist diese Unterscheidung entscheidend, da Fehler in der Problemdefinition zu kostspieligem Neubau von Werkzeugen und Formen führen können.

Wie integrieren Sie Fertigbarkeit und Zertifizierungsanforderungen in die erste Diamantform?

Sie wenden Design for Manufacturing-Prinzipien bereits während der Problemdefinition an und beziehen Produktionsexperten in die Festlegung der Anforderungen ein. Zertifizierungsanforderungen nehmen Sie als harte Randbedingungen ins Product Decision Pack auf, damit sie die Architekturentscheidungen steuern und nicht nur einen nachträglichen Gedanken darstellen.

Was enthält ein Product Decision Pack und warum ist es essenziell?

Es enthält alle technischen, finanziellen und regulatorischen Validierungen, die nötig sind, um verantwortungsbewusst in die Entwicklung zu gehen, einschließlich Kostenkalkulationen und Machbarkeitsnachweisen. Dieses Dokument bildet die Brücke zwischen Design Thinking und Engineering und verhindert, dass Teams in der Develop-Phase an unvorhergesehenen Hindernissen scheitern.