App laten testen met gebruikers

De meeste feedback op een app is onbruikbaar, en dat ligt niet aan de mensen die hem geven maar aan de vraag. Vraag je wat iemand van een scherm vindt, dan vraag je een oordeel over iets dat hij nog niet gebruikt heeft. Hij zegt iets over de kleur, jij loopt weg met de indruk dat het goed zit.

Twee dingen werken tegen je. Mensen zijn slecht in het voorspellen van hun eigen gedrag: "ja, dat zou ik gebruiken" is geen belofte maar een beleefde inschatting. En mensen zijn aardig tegen de maker, want niemand kraakt je werk af terwijl je erbij zit. Vervang de vraag door een opdracht en kijk toe. Waar de cursor stilstaat en waar iemand terugklikt, dat zijn feiten. Een mening kun je wegwuiven, drie deelnemers die dezelfde knop niet vinden niet.

Links vraag je naar iets dat echt gebeurd is; rechts naar een voorspelling, een oordeel of een ontwerp. "Is dit zo duidelijk?" bevat het antwoord al. Zegt een deelnemer dat er een knop bij moet, dan zocht hij daar iets wat er niet was. Noteer de aanleiding, niet de oplossing.

Veel teams laten deelnemers hardop denken. Dat werkt, maar praten terwijl je iets doet is onnatuurlijk en deelnemers filteren hun gedachten, zoals de toelichting van NN/g beschrijft. Het is aanvulling op wat je ziet, geen vervanging.

Nielsen Norman Group kwam met het bekendste getal: met vijf deelnemers vind je ongeveer 85 procent van de bruikbaarheidsproblemen. Dat komt uit een model waarin één deelnemer gemiddeld zo'n 31 procent van de problemen tegenkomt. NN/g zet er in het oorspronkelijke artikel en in hun overzicht over aantallen zelf grenzen omheen: wil je iets in cijfers meten, dan gaan ze naar minstens twintig deelnemers, voor card sorting naar vijftien en voor eyetracking nog verder. En liever drie rondes van vijf dan één van vijftien.

De kritiek richt zich niet op dat gemiddelde, maar op de spreiding eromheen. Laura Faulkner liet in 2003 zestig mensen hetzelfde systeem gebruiken en trok daar willekeurig groepjes van vijf uit. Gemiddeld vonden die rond de 85 procent, maar de uitkomsten liepen uiteen van 55 tot 99 procent. Bij tien deelnemers kwam de slechtste groep op 80 procent, bij twintig op 95 procent (Faulkner, 2003). Je weet vooraf niet welk groepje je hebt. Bovendien is die 31 procent een gemiddelde uit onderzoek naar systemen met veel gebreken; bij een product dat al draait komen problemen minder vaak voor, en vindt datzelfde groepje van vijf dus minder, zoals MeasuringU uitlegt.

Praktisch: vijf deelnemers zijn genoeg om te beginnen, mits je repareert wat je vindt en opnieuw test. Ze zijn niet genoeg om te concluderen dat er niets meer mis is. Zie het getal dus als startpunt per ronde, niet als eindstand.

Belangrijker dan de vorm is wie er in de stoel zit. Mensen uit je netwerk zijn het makkelijkst en het minst bruikbaar: ze kennen jou en willen je niet teleurstellen. Iemand die het probleem echt heeft, levert in één sessie meer op dan drie vrienden samen. Hoe je die vindt behandelen we in beta-testers vinden voor je app.

Je hebt hier geen werkend product voor nodig. Een klikbaar prototype, een reeks schermen die echt op elkaar reageren, is genoeg om iemand een taak te geven en te zien waar hij vastloopt. Dat is ook het moment waarop veranderen nog goedkoop is: je verplaatst een stap in een ontwerp, niet in een codebase met klantgegevens erin. Snelheid en gedrag op langere termijn test je zo niet, maar of mensen begrijpen wat je gemaakt hebt, weet je nu al.

Wij bouwen in één werkdag zo'n klikbaar prototype. Wil je dat wij de sessies opzetten, dan loopt dat via prototype testen. Twijfel je of het idee zelf hout snijdt, begin bij je app-idee valideren.