Double Diamond Design framework voor fysieke producten

Het Double Diamond design framework is een krachtig instrument om innovatie te structureren, maar voor fysieke producten schiet de standaardversie vaak tekort. Het zwaartepunt ligt bij digitale diensten en gebruikerswensen. Wie een tastbaar product wil lanceren, ontdekt al snel dat wenselijkheid alleen geen garantie is voor succes: zonder vroege validatie van techniek, kostprijs en maakbaarheid blijft een goed idee slechts een belofte.

Dit artikel legt uit hoe je het model toespitst op hardware en kunststofproducten, zodat je niet pas in de ontwikkelfase ontdekt dat je fundament wankelt.

Wat is het Double Diamond model in de praktijk?

Het Double Diamond design framework organiseert innovatie in vier fasen die afwisselend divergerend en convergerend zijn: Discover, Define, Develop en Deliver. In de eerste diamant verken je breed het probleemgebied. Daarna definieer je scherp wat je precies gaat oplossen, waarna de tweede diamant hetzelfde patroon herhaalt voor het ontwerpen en realiseren van de oplossing.

Deze methode dwingt teams om niet direct naar oplossingen te springen, maar eerst zekerheid te bouwen over de vraagstelling.

Bij digitale toepassingen werkt dit uitstekend, want iteraties zijn goedkoop en feedbackcycli kort. Bij fysieke productontwikkeling vraagt elke fase juist extra discipline rond technische en financiële kaders. De standaarduitleg van het Double Diamond design framework richt zich meestal op dienstverlening of software, waar je aannames snel kunt testen met prototypes die nauwelijks kosten.

Voor makers van fysieke goederen is die luxe er niet.

Je moet daarom vanaf dag één rekening houden met beperkingen die in een digitaal proces pas veel later relevant worden: materiaalkunde, assemblagevolgorde, certificeringstrajecten. Zonder deze aanpassing loop je na een perfecte Discover-fase alsnog vast in de engineering.

Waarom eerst het probleem valideren en dan pas de oplossing?

Het strikt scheiden van probleem- en oplossingsruimte voorkomt dat organisaties investeren in producten waarvoor geen reële marktbehoefte bestaat, en dat kan bij fysieke innovatie desastreus uitpakken door de hoge ontwikkelkosten en lange doorlooptijden. Een gevalideerd klantinzicht is fundamenteel iets anders dan een aanname: het rust op bewijs uit de praktijk, niet op interne overtuigingen of veronderstelde wensen van stakeholders.

Veel productteams starten onbewust toch vanuit een oplossing.

Ze hebben een technisch concept of een esthetisch voorbeeld en zoeken daar vervolgens een probleem bij. Dat levert producten op die weliswaar ingenieus zijn, maar die niemand echt nodig heeft. Binnen de Define-fase van het Double Diamond design framework betekent validatie dat je onzekerheden wegneemt met data en gesprekken, niet met brainstormsessies of managementgutfeelings.

Pas als het probleem scherp staat én bevestigd is door de doelgroep, mag je de oplossingsruimte betreden.

Deze discipline voelt soms als vertraging, maar het is juist de enige manier om latere, veel duurdere faalkosten te voorkomen. Bij fysieke producten herstel je een fout in de probleemdefinitie niet met een update of patch; je moet terug naar de tekentafel en opnieuw gereedschap maken.

Waarom het standaardmodel tekortschiet bij fysieke producten

Desirability is noodzakelijk, maar nooit voldoende voor hardware: een gewenst product dat niet produceerbaar of betaalbaar is, bestaat commercieel gezien niet. Het standaard Double Diamond design framework behandelt technische haalbaarheid, kostprijsbepaling, certificeringseisen en productiecapaciteit vaak als latere zorgpunten, terwijl ze bij fysieke innovatie net zo zwaar wegen als gebruikerswensen.

Een briljant ontwerp faalt als de matrijs niet te maken is.

Neem je deze harde randvoorwaarden pas mee in de Develop-fase, dan ontdek je problemen op een moment dat aanpassingen extreem kostbaar zijn geworden. Je kiest niet zomaar een ander materiaal of past een tolerantie aan zonder gevolgen voor de hele keten, van leverancier tot eindassemblage.

Daarom moeten technische en financiële eisen gelijkwaardige partners zijn in de definitiefase.

PEZY voegt in de Define-fase technische, financiële en productiekennis toe aan het innovatieproces om de kloof tussen idee en maakbaarheid te dichten. Zo weet je niet alleen wat de klant wil, maar ook wat het mag kosten, welke certificeringen nodig zijn en of de kritische functie technisch überhaupt realiseerbaar is binnen de gestelde kaders.

Zonder deze integratie blijft je eerste diamant een oefening in wensdenken.

Technische en financiële randvoorwaarden integreren in Define

Voordat je start met ontwikkeling moet glashelder zijn of de kritische functie technisch kan werken, wat het product maximaal mag kosten en welke investering in tooling en certificering realistisch is binnen de businesscase. Deze vragen lijken voorbarig tijdens de probleemverkenning, maar ze vormen juist de filter die onderscheid maakt tussen een leuk idee en een levensvatbaar product.

Een goed idee is nog geen productbeslissing.

Voor fysieke producten moet eerst duidelijk zijn of de kritische functie technisch kan werken en wat het product mag kosten, voordat je verder investeert in detaillering. In de Define-fase moet je daarom al technische haalbaarheid valideren via gerichte tests, niet via theoretische studies of leveranciersbeloftes.

Maakbaarheid is geen abstract begrip, maar een rekenkundige werkelijkheid.

Door vroegtijdig Design for Manufacturing principes toe te passen, voorkom je dat je een ontwerp definieert dat wel voldoet aan de gebruikerswens maar niet tegen de juiste kostprijs geproduceerd kan worden. Certificeringseisen horen hier ook thuis: een CE-markering of medische goedkeuring bepaalt vaak de architectuur van het product en de keuze voor materialen.

Neem je dit niet mee in je definitie, dan bouw je onvermijdelijk aan een product dat later niet door de keuring komt.

Kritische functies en kostprijs als harde eisen

De kostprijs is geen uitkomst van het ontwerpproces, maar een voorwaarde die je meeneemt in de probleemdefinitie, net als de technische prestaties die het product minimaal moet leveren. Reken je pas na het detailleren, dan kom je vaak bedrogen uit en moet je concessies doen aan de functionaliteit of kwaliteit die je in de Discover-fase hebt beloofd.

Stel de kostprijsdoelstelling daarom vast als onderdeel van je Product Decision Pack.

Certificering en productiecapaciteit vroegtijdig borgen

Certificeringstrajecten duren maanden en vereisen specifieke testopstellingen. Daarom moet je de eisen kennen voordat je het product vormgeeft, niet pas wanneer het prototype klaarstaat voor validatie. Hetzelfde geldt voor productiecapaciteit: ken je seriegroottes of cyclustijden niet, dan kun je geen betrouwbare businesscase maken.

Deze kennis hoort thuis in de eerste diamant.

Van eerste diamant naar een complete productbeslissing

De overgang van abstracte inzichten naar concrete engineering vraagt om een document dat fungeert als brug tussen design thinking en technische realisatie, zodat latere fases niet vastlopen op onverwachte blokkades. Het Product Decision Pack vormt de concrete uitkomst van PEZY Define en bevat de validaties die nodig zijn om verantwoord aan ontwikkeling te beginnen, inclusief de antwoorden op de vragen over techniek, kosten en regelgeving.

Dit pakket is meer dan een specificatielijst.

Het is het bewijs dat je probleemdefinitie robuust genoeg is om de investering in de Develop-fase te rechtvaardigen. Bij het productspecificatie opstellen vertaal je gebruikerseisen naar technische parameters die getoetst zijn aan maakbaarheid en kostprijs, waardoor engineers niet hoeven te gissen naar de intentie achter de eisen.

Zonder dit fundament is elke ontwikkelstart een gok.

Veel organisaties slaan deze stap over omdat ze denken dat hun Discover-resultaten voldoende zijn, maar dan missen ze de cruciale laag van technische en financiële validatie. Een PEZY Define traject levert precies deze ontbrekende schakel, zodat je met vertrouwen de tweede diamant ingaat.

Het Product Decision Pack als fundament

Dit document bundelt alle validaties, risico-analyses en randvoorwaarden die nodig zijn om de Develop-fase te starten zonder dat het team later terug moet naar de tekentafel door gemiste eisen. Het dwingt het team om vaagheden te elimineren en expliciete keuzes te maken over wat wel en niet in scope is.

Checklist: gereedheid voor de Develop-fase

Je bent pas klaar voor ontwikkeling als de kritische functie is aangetoond, de kostprijs is onderbouwd, de certificeringsroute bekend is en de productiepartner betrokken is bij de specificaties. Ontbreekt één van deze elementen, dan is je productbeslissing prematuur en loop je onnodig financieel risico.

Gebruik deze criteria als poortwachter.

De rol van prototyping en TRL in het Double Diamond proces

Theorie en praktijk komen samen in gerichte validatiemomenten, specifiek gericht op het wegnemen van technische onzekerheden voordat je de volledige ontwikkelcapaciteit inzet. Waar digitale teams werken met clickable prototypes, moet je bij fysieke producten tastbaar bewijs leveren dat de gekozen technologie werkt onder reële omstandigheden, en niet alleen in een labopstelling.

Dit vraagt een andere benadering van prototyping.

Een Proof of Concept is in dit kader geen ruw modelletje om een idee te visualiseren, maar een gericht experiment dat antwoord geeft op de meest risicovolle technische vraag uit je definitie. Door dit te koppelen aan de Technology Readiness Level schaal, maak je technologische volwassenheid meetbaar en vergelijkbaar, essentieel voor investeringsbeslissingen.

Zo voorkom je dat je ontwikkelt op basis van hoop.

Proof of Concept als validatiemoment

Een PoC test uitsluitend de kritische functie of het grootste technische risico en heeft geen esthetische of ergonomische waarde, want het doel is puur risicoreductie, niet presentatie. Faalt de PoC, dan heb je gefaald in de Define-fase en niet in de ontwikkeling, en dat is precies de bedoeling van het Double Diamond design framework voor fysieke producten.

Falen hier is winst.

Technology Readiness Level als maatstaf

De TRL-schaal biedt een objectief kader om te beoordelen of een technologie rijp genoeg is voor integratie in een product, waardoor discussies over ‘haalbaarheid’ plaatsmaken voor gestandaardiseerde scores. Dit helpt R&D-leads en productmanagers om voortgang te rapporteren en beslismomenten te koppelen aan feitelijke maturiteit in plaats van aan planningsoptimisme.

Wanneer is je product écht klaar voor de Develop-fase?

Je product is pas klaar voor de Develop-fase als je naast een gevalideerd klantprobleem ook beschikt over een technisch haalbaarheidsbewijs, een onderbouwde kostprijsberekening en een duidelijke route naar certificering en serieproductie. Het Double Diamond design framework levert deze zekerheid niet automatisch; je moet het model actief aanvullen met engineering- en bedrijfskundige validaties om teleurstellingen in latere fasen te voorkomen.

Ontbreekt deze zekerheid, dan is doorgaan onverantwoord.

Gebruik de eerder genoemde checklist als harde gate, en wees bereid om terug te gaan naar de Define-fase als er gaten zitten in je onderbouwing. Voor organisaties die deze zekerheid zoeken maar zelf niet over de brede expertise beschikken, is een gespecialiseerd traject vaak de snelste weg naar een valide productbeslissing.

Maakbare innovatie begint bij een eerlijke definitie.

Veelgestelde vragen over Double Diamond voor fysieke producten

Hoe verschilt het Double Diamond model voor fysieke producten van de standaard design thinking aanpak?

Bij fysieke producten weeg je technische haalbaarheid, kostprijs en maakbaarheid al in de eerste diamant mee als gelijkwaardige factoren naast gebruikerswensen. Standaard design thinking focust vaak primair op desirability en laat technische validatie over tot de ontwikkelfase, wat bij hardware leidt tot kostbare late wijzigingen.

Welke criteria moeten gevalideerd zijn voordat een fysiek product de Develop-fase ingaat?

De kritische functie moet technisch zijn aangetoond via een Proof of Concept, de maximale kostprijs moet zijn onderbouwd en de certificeringsroute moet bekend zijn. Ook moet duidelijk zijn of de beoogde productiecapaciteit en investering realistisch zijn binnen de businesscase.

Wat is het verschil tussen een gevalideerd klantinzicht en een aanneme in de Define-fase?

Een gevalideerd inzicht is gebaseerd op bewijs uit de praktijk, zoals gebruikerstests of marktonderzoek, terwijl een aanneme rust op interne overtuigingen of ongecheckte hypothesen. Bij fysieke producten is dit onderscheid cruciaal omdat fouten in de probleemdefinitie leiden tot dure herbouw van tooling en mallen.

Hoe integreer je maakbaarheid en certificeringseisen in de eerste diamant?

Je past Design for Manufacturing principes toe tijdens de probleemdefinitie en betrekt productie-experts bij het stellen van de eisen. Certificeringseisen neem je mee als harde randvoorwaarde in je Product Decision Pack, zodat ze sturend zijn voor de architectuurkeuzes in plaats van een afterthought.

Wat bevat een Product Decision Pack en waarom is dit essentieel?

Het bevat alle technische, financiële en regulatorische validaties die nodig zijn om verantwoord aan ontwikkeling te beginnen, inclusief kostprijsberekeningen en haalbaarheidsbewijzen. Dit document vormt de brug tussen design thinking en engineering, en voorkomt dat teams in de Develop-fase vastlopen op onvoorziene blokkades.