Vraag niet wat iemand bedoelt, vraag wat hij ziet

Waarom loopt een gesprek over techniek zo vaak vast?

Wie uitlegt dat de ander iets verkeerd zegt, heeft gelijk en lost niets op. Vraag in plaats daarvan wat er op het scherm staat, welke knop er zit, wat er precies gebeurt. Dan blijkt vaak binnen dertig seconden dat er geen meningsverschil is maar een woordverschil — en die zijn wél op te lossen.

Dat klinkt als een gespreksadvies. Het is de kern van hoe een functioneel ontwerp tot stand komt.

Een hoofdletter negen

Een klant belde: wachtwoord kwijt. Wij kennen wachtwoorden van klanten niet en slaan ze niet op, dus stelden we voor het samen door te lopen, teken voor teken.

Bij een van de tekens zei ze: “hoofdletter negen”. Wij zeiden dat die niet bestaat — een cijfer heeft geen hoofdletter. Waarop zij: jazeker wel, dat heb ik zelf ingetikt.

Welles, nietes, over een hoofdletter negen die niet bestaat.

Het was de hoofdletter G. Zij zag een cijfer, wij hoorden een cijfer, en er stond een letter.

Waarom “dat bestaat niet” het gesprek beëindigt

Omdat het klopt. Dat is precies het probleem.

Zolang u uitlegt dat de ander de verkeerde woorden gebruikt, staat u samen stil. U hebt gelijk, hij voelt zich dom, en het onderliggende ding — het wachtwoord, de fout, de wens — is geen millimeter dichterbij.

De vraag die wél werkt is niet “wat bedoelt u”, want dat vraagt om een vertaling die de ander niet kan maken. De vraag is: hoe ziet het eruit. Wat staat er. Waar staat het.

Dat is geen beleefdheidstruc. Het is het verschil tussen twee mensen die om elkaar heen praten en twee mensen die naar hetzelfde scherm kijken.

Wat dit betekent voor een softwareproject

Bijna elke wens die wij opgeschreven krijgen, komt binnen in de taal van de klant. Dat is de goede taal — het is zijn bedrijf. Maar hij beschrijft wat hij *wil* in termen van wat hij *nu doet*, en dat zijn twee verschillende dingen.

“Ik wil dat het systeem de order doorzet” kan tien dingen betekenen. Vraag wat er nu op het scherm gebeurt en u krijgt er één: hij typt een nummer over uit een ander venster, twee keer per dag, en soms staat het er niet in.

Dat verschil is precies waar het functioneel ontwerp over gaat. Niet opschrijven wat iemand vraagt, maar opschrijven wat er gebeurt — en dan pas bedenken wat er anders moet.

Wie die stap overslaat, bouwt keurig wat er gevraagd is en levert iets op dat niemand gebruikt.

Waarom dit ook bij AI misgaat

Een taalmodel doet precies wat hier misgaat, maar dan sneller. Het vertaalt uw woorden naar iets plausibels en geeft antwoord alsof het de vraag begrepen heeft. Het vraagt zelden terug hoe iets eruitziet.

Daarom is “vraag wat iemand ziet” geen ouderwets advies dat door techniek achterhaald wordt. Het is juist het deel dat een mens moet doen — zie ook waarom AI te vaak ja zegt.

Wat een kleine klus voor de ander betekent

Er zit nog een tweede les in dat telefoongesprek, en die gaat niet over taal.

Voor ons was het een klein klusje op een vrijdagmiddag. Voor haar was het de reden dat ze die week weer bij haar kleinkinderen op de foto kon. Wat voor u routine is, is voor de ander soms het hele punt.

Dat is niet sentimenteel. Het bepaalt hoeveel geduld u opbrengt op het moment dat het gesprek vastloopt — en dat moment komt in elk project.

Stel die ene vraag in het volgende gesprek

Bij het eerstvolgende gesprek waarin u merkt dat u iets aan het uitleggen bent.

Stop met uitleggen en stel één vraag: wat ziet u nu op uw scherm? Tel hoe vaak het daarna nog misgaat. Bij ons is dat aantal flink gedaald, en er is geen software voor nodig.

Waar dit verhaal vandaan komt

Dit gebeurde echt, aan de telefoon, op een vrijdagmiddag. Marc schreef het op als Hoofdletter negen — een klant is nooit dom, hij praat anders.