In team is het nodig de voortgang op een duidelijke manier aan elkaar door te geven. Tevens zijn technieken nodig om de aandacht te richten op de erkende verbanden, op conflictsituaties waar bestaande technische oplossingen niet compatibel zijn en op eventuele lacunes. Het is hierbij gebruikelijk om alle aspecten in matrix vorm weer te geven zodanig dat men een concrete focus heeft in het team: zowel vage wensen als duidelijke technische beperkingen met meeteenheid, target en benchmark worden hier ingevuld. Uiteindelijk zullen alle verwachtingen in minstens een of andere testbare eigenschap van het ontwerp moeten omgezet worden.

Het opstellen van de matrix zelf is voor een team dikwijls een eerste ontwerpbenadering. Het feit dat men probeert te weten te komen wat de eisen zijn van de klant is reeds een eerste conceptueel ontwerp: het is op zoek gaan naar die dingen die van belang zijn, welke verder in het ontwerp niet meer mogen variëren, en welke nog anders ingevuld kunnen worden. Het waarnemingsmodel evolueert dus in de tijd en geeft dus op elk moment de stand van zaken van de opgebouwde kennis, en resulteert uiteindelijk in een model met enkel nog de aspecten van een ontwerp die een verschil zullen maken dat een verschil maakt.

De matrix heeft als algemene vorm:

In de meest linkse kolom worden alle verwachtingen in rijen gelijst. Gewoonlijk wordt de matrix gemakkelijk leesbaar gemaakt en worden de verwachtingen nog eens onderverdeeld (of uitgesplitst) in paragrafen over bijvoorbeeld functionele eisen, uitzicht, omgeving, kosten, tijd van ontwikkeling, productiebeperkingen als machines, materialen, gereedschappen, interacties en compatibiliteit met geassocieerde producten (denk maar aan wisselstroom specificaties, maar ook de-facto industrie standaards, beschikbaarheid van software enz...), potentieel voor groei en uitbreiding, patenten en normen, veiligheid en aansprakelijkheid, documentatie en training, service en onderhoud, kwaliteit en betrouwbaarheid, milieu, ergonomie, enz...naargelang de soort klant die hierbij betrokken is. Indien dit echter a priori gedaan wordt, dan wordt eigenlijk het ontwerp al erg in die relevant geachte categorieën ondergebracht en kan dit de creativiteit belemmeren. Het is beter deze categorieën ook organisch te laten ontstaan in de loop van het ontwerp.

In de tweede kolom dwingt men zichzelf binnen een totale score van 100 het relatieve gewicht van de verschillende wensen weer te geven. De eisen die absoluut moeten vervuld worden spelen hierbij niet mee omdat men nooit met een relatieve keuze hierover zal geconfronteerd worden.

In de bovenste rij van de volgende kolommen lijst men de testen waarmee men het ontwerp meetbaar kan beoordelen. Die krijgen dan onderaan een meetbaar doel (target, datgene wat zou moeten bereikt kunnen worden), en een gemeten benchmark (typisch een meting aan een concurrerende of een vroegere oplossing: een benchmark is steeds iets dat reeds gerealiseerd geweest is). Dit waarborgt dat de meting effectief aan iets bestaands kan uitgevoerd worden. Elke cel in de bovenste rij moet kunnen beginnen met het werkwoord: “neem X waar in de meetcontext en meetprocedure Y”. Deze matrix relateert dus begrippen (namen) met de manier waarop de stakeholder het begrip expliciet (voor eisen) of impliciet (voor wensen) zal kunnen ervaren.

De centrale vakken van deze kolommen geven de validering weer (de relatieschatting tussen eisen en wensen en meetprocedures) met symbolen of cijfers.

In de laatste kolommen probeert men voorbeelden van bestaande oplossingen in klantenvoldoening te beoordelen. Die benchmark moet breed gezien kunnen worden. Relevante benchmarks liggen soms in een onverwacht gebied. Zo is bijvoorbeeld een biermerk tot de conclusie gekomen dat een bepaald soort frisdrank tot een nieuwe norm geleid heeft wat betreft verwachtingen wat betreft "de manier van drinken". Typisch kan men ook hier geen ratio meetbare gegevens gebruiken en moet men zijn toevlucht nemen tot ordinale beoordelingen.

Een voorbeeld.

Deze techniek is gelijkaardig maar fundamenteel verschillend van de "Quality Function Deployment" (QFD) techniek die uit een focus op kwaliteitsverbetering van een bestaand ontwerp ontstaan is. In de klassieke QFD gaat men klanteneisen en klantenwensen omzetten in technische specificaties. Het fundamenteel verschil met de ontwerpbenadering is dat die technische specificaties enkel in een technische context meetbaar zijn en enkel voor technische stakeholders zinvol zijn. Dat betekent dat men hier veronderstelt dat de vertaling (door correlatie onderzoek bijvoorbeeld) van een waarneming van de klant naar een technische context reeds gebeurd is. Dat is een heel zware veronderstelling die zeker nog niet mogelijk is in het begin van het ontwerp proces, maar pas als het ontwerp reeds volledig gematerialiseerd is. De QFD techniek gaat dan nog verder en men zal zo'n matrix opstellen voor de verschillende functies in het bedrijf die elkaars klanten zijn. Zo vindt men matrices die de klantenwensen omzetten in technische functies (een ontwikkeling functie in het bedrijf), technische functies omzetten in technische eisen (een engineering functie in het bedrijf, die een klant is van de vorige functie), technische eisen omzetten in proceshandelingen (een werkvoorbereiding functie in het bedrijf, klant van de engineeringfunctie), proceshandelingen omzetten in productiebenodigdheden (een planningsfunctie in het bedrijf, klant van de werkvoorbereidingfunctie). De klassieke QFD matrix wordt eigenlijk gekarakteriseerd door het "dak" ervan waarin relaties aangegeven worden tussen de verschillende kolommen die aangeven welke uitvoeringen met de huidige stand van de techniek niet of moeilijk verenigbare oplossingen bieden voor de klantenverwachtingen. Kwaliteitsverbeteringen worden dan ook mogelijk door zich juist op die conflictgebieden te concentreren.