Op 10, 11 en 12 april waren wij op UX London, een jaarlijks evenement voor User Experience ontwerpers. Er waren veel nuttige en interessante sessies, met (voor mij) als hoogtepunten de presentaties van Genevieve Bell over cultureel bepaalde angst voor technologie en Simone Ribaudengo over zijn via internet verbonden broodroosters die alleen gelukkig werden van brood roosteren (en van geaaid worden).

De grootste eye-opener was voor mij echter de presentatie van Jeff Gothelf over Lean UX, en dan vooral de uitspraak waar hij al direct mee begon: “Requirements are actually assumptions”.

Als een klant bij je komt met een mogelijke opdracht heeft hij meestal al een programma van eisen (“requirements”) opgesteld. Er is intern nagedacht wat er ontworpen of gebouwd moet worden, de klant weet wat hij wil (“we hebben rekenmodule X nodig”) en vraagt nu om een prijsopgave of om het uitvoeren van de benodigde functionaliteiten.

Maar eigenlijk is zo’n programma van eisen maar een aanname van de klant: een interpretatie van het probleem en hoe dat opgelost moet worden. Wij zijn allemaal geneigd om het programma van eisen te geloven, en te gaan ontwerpen/bouwen wat de klant vraagt.

Verspilde moeite

Dit leidt echter vaak tot “waste”: het bouwen van functionaliteiten waar de klanten van je klant helemaal niet op zitten te wachten, dure dingen die vervolgens niet gebruikt worden of niet bijdragen aan het bereiken van de bedrijfsdoelstellingen. Je kent het wel: lege discussieforums, producten waar geen behoefte aan bestaat, opgetuigde kerstbomen aan functionaliteit die uiteindelijk niet méér klanten opleveren.

Misschien moeten we daarom het programma van eisen van onze klanten helemaal niet zo klakkeloos gaan uitvoeren. Misschien moeten we iedere functionele eis openlijk een aanname noemen, en hem ook als zodanig behandelen.

Wat is het probleem?

Als je hardop zegt dat iets een aanname is, dan kun je er namelijk ook een discussie over beginnen. Als je zegt ‘wij geloven dat we een weblog nodig hebben om onze klanten te bereiken’ dan kun je vervolgens openlijk praten over hoe dat geloof tot stand is gekomen. Over welke klanten praat je? Welke informatie willen ze daar dan vinden? Welk probleem gaat dat oplossen? Is er niet een andere manier waarop we hetzelfde kunnen bereiken, maar met een veel geringere inspanning?

Je moet er naartoe dat je gezamenlijk, dus met mensen van klantzijde en ontwerpers/bouwers, bespreekt welk probleem we hier aan het oplossen zijn. Als je samen tot overeenstemming bent gekomen over wat het probleem is, kun je hypotheses gaan opstellen over hoe je het probleem kunt gaan oplossen. Gothelf heeft daar een mooie formule voor:

We believe that [building this feature] [for these people] will achieve [this outcome]. We will know we are successful when we see [this signal from the market].

Wat zijn goede uitkomsten?

Praten over hoe je kunt zien dat je het probleem succesvol hebt opgelost is minstens zo belangrijk (en moeilijk!) als het praten over de aannames, zegt Gothelf. Voordat je begint met iets bouwen moet je er al over nadenken hoe je de resultaten gaat meten, en wat de juiste resultaten zijn. Hoe kunnen we buiten, in de wereld, zien dat onze interventie succes heeft gehad?

“Meer bezoekers” is bijvoorbeeld bijna nooit een goede uitkomst op zich, omdat dat alleen bijdraagt aan je bedrijfsresultaat als je advertenties verkoopt. “Een hoger percentage mensen dat na het kijken van onze demo een abonnement afsluit” is al een veel beter geformuleerde uitkomst.

Hypotheses en experimenten

Jeff Gothelf stelt voor dat we allemaal gaan groeien richting de “experimentation mindset”: hypotheses opstellen zoals hierboven, veel snelle experimenten uitvoeren en kijken wat het oplevert. Zijn de uitkomsten niet de juiste? Dan gaan we snel het volgende experiment uitvoeren en kijken of dat wél werkt.

Uitgangspunt hierbij is steeds “minimize waste”: zo min mogelijk werk stoppen in de dingen die je weer weg moet gooien als ze niet blijken te werken. Zoek altijd naar het minimum viable product: wat is het simpelste ding dat je kunt bedenken om je hypothese te testen?

Maar het begint dus allemaal met de moed om tegen je klant te zeggen: je programma van eisen staat eigenlijk vol aannames, laten we samen onderzoeken wat je échte business-probleem is, en dat proberen op te lossen. Eng, maar erg waardevol, denk ik.