Ontwerpers zijn opgeleid om maximaal rekening te houden met de eisen en wensen van alle betrokkenen bij een ontwerp (in het ontwerpjargon worden dit stakeholders genoemd). Een ontwerper moet dus de werkelijkheid van elke stakeholder zo goed mogelijk leren kennen, en dit is de werkelijkheid zoals ze beleefd wordt vanuit het gezichtspunt van de stakeholder.

Concreet betekent dit dat de ontwerper zijn ontwerpproces aanvangt met een zoektocht om aspecten van een ontwerp te creëren en ervaarbaar te maken voor elke stakeholder, met de capaciteiten en contexten die voor de stakeholder relevant zijn. Er zullen immers altijd aspecten zijn die irrelevant zijn voor een bepaalde stakeholder, maar relevant voor een andere, wat typisch aanleiding geeft tot verschillende “methodologieën”. Met een concreet voorbeeld: het is voor de eindgebruiker van een product dat in de distributieketen per 16 op een palet kan gestapeld worden irrelevant dat de product/verpakking combinatie ook de gespecificeerde transportbelasting kan opnemen.

De ontwerper gaat op zoek, deels naar aspecten die op voorhand gekend zijn, en dus op voorhand in bestaande categorieën kunnen ondergebracht worden, maar ook naar aspecten die helemaal nieuw zijn en wellicht aanleiding geven tot nieuwe categorieën waarin bestaande aspecten achteraf kunnen geïnterpreteerd worden. Bestaande aspecten worden als benchmarks gedocumenteerd.

Een aspect kan twee facetten hebben: wat wil de stakeholder ervaren en wat wil hij vermijden. Benoemen echter is op zich niet voldoende. De ontwerper moet weten hoe (met welke middelen, in welke context, ...) hij die aspecten in de loop van het ontwerpproces zelf zou kunnen testen op een manier die ook relevant zal bevonden worden door de stakeholder. Dit noemen we “operationaliseren”.

Door informatie in te winnen bij alle betrokkenen divergeert de ontwerper zijn manier om de opdracht te begrijpen met de aspecten die relevant zijn voor die bepaalde stakeholder. Hij isoleert hiermee ook die aspecten die door meerdere stakeholders relevant bevonden worden en die tot incompatibiliteit zouden kunnen aanleiding geven, wat betekent dat stakeholder 1 een bepaalde verwachting aangaande het aspect in een bepaalde context zou hebben dat door stakeholder 2 juist daar en dan niet verwacht wordt.

In de taal van het haakformalisme.

Elk aspect heeft twee facetten: X en “iets anders dan X” (wat in het haakformalisme de vorm krijgt: <X> en we ook de “inbedding van X” noemen). Men kan X ervaren of men kan X vermijden. Bij het ervaren van X zal men “iets anders dan X” vermijden, bij het vermijden van X zal men “iets anders dan X” ervaren. Een werkelijkheid die opgebouwd is op basis van testbare aspecten heeft een traliestructuur met <> en <<>> op de extremen. Hiertussen liggen welgevormde haakuitdrukkingen die aspecten representeren en die opgebouwd zijn op basis van logische operaties op onderliggende onderscheidingen die voor het overgrote deel voor de stakeholder onbewust zijn. De logica van de stakeholder is niet de logica van de aspecten die hij vermeldt, maar de logica van de onderliggende onderscheidingen die voor hem grotendeels onbewust, of vanzelfsprekend zijn en die hij dus niet communiceert aan de ontwerper. Dit heeft als typisch gevolg dat de ontwerper tijdens zijn onderzoek om te weten te komen wat nu echt relevant is voor een bepaalde stakeholder, geconfronteerd wordt met gedrag dat afwijkt van wat hij verwachtte op basis van de algemeen aanvaarde kennis van product en context.

Informatie inwinnen betekent dan voor de ontwerper dat hij voornamelijk aandacht heeft voor de inherente structuur van de aspecten die door de stakeholder wel vermeld worden. Die inherente structuur kan de ontwerper op het spoor komen door hypothesen te formuleren (met behulp van de vaardigheid om creatief te exploreren) die met de stakeholder kunnen (met behulp van de vaardigheid van te beslissen) afgetoetst worden (met behulp van testen). De structuur die resulteert zal veel hiaten vertonen, wat betekent dat de resulterende tralie weinig suprema zal vertonen die ook infima zijn (of volledig duaal hiervoor: weinig infima die ook suprema zijn). Mogelijkheden genoeg dus voor de ontwerper om met nieuwe entiteiten voor de dag te komen die voor de stakeholder als passend in zijn wereldbeeld kunnen herkend worden.

Informatie inwinnen betekent dus dat de ontwerper kiest om het relevante universum uit te breiden met aspecten waarmee hij rekening zal moeten houden om de manier die in die context door de betrokkenen als relevant kan herkend worden.

Informeren is dus kiezen om te divergeren.