Usabilitytesten hebben ten onrechte de reputatie duur en traag te zijn. Bij "user research" denken mensen aan een doorkijkspiegel, een moderator met een klembord en een doorlooptijd van twee weken. Die vorm van testen bestaat en heeft zijn nut — maar het is niet de vorm die de meeste productteams meestal nodig hebben.
De vorm die de meeste teams nodig hebben, is eenvoudiger: vijf gebruikers, een Figma-prototype of een stagingomgeving, een videogesprek en 45 minuten per sessie. Goed uitgevoerd brengt dit het merendeel van de ernstige usabilityproblemen aan het licht voordat het product live gaat. Doe je het consequent — al is het maar eens per sprint — dan levert het een zichzelf versterkende verbetering van de productkwaliteit op die geen enkele hoeveelheid analytics na de lancering kan evenaren.
Zo pak je het vanaf nul aan.
Vijf deelnemers is het juiste aantal voor de meeste usabilitytests. Uit het onderzoek van Jakob Nielsen bleek dat vijf gebruikers ongeveer 85% van de usabilityproblemen aan het licht brengen, waarna de meeropbrengst afneemt. Drie rondes met vijf gebruikers op verschillende momenten in het ontwerpproces leveren meer op dan één sessie met vijftien.
De wervingscriteria zijn belangrijker dan het aantal. Een usabilitytest met vijf mensen die goed bij je doelgebruiker passen, onthult echte problemen. Een test met vijftien mensen die niet passen, levert alleen ruis op. Bepaal twee of drie selectiecriteria — rol, gebruikscontext, technische vaardigheid — en houd je eraan.
De snelste wervingsroute voor de meeste teams is het mailen van bestaande gebruikers die toestemming hebben gegeven om contact op te nemen. Bied een bescheiden beloning aan — een cadeaubon van £20 is genoeg voor een sessie van 45 minuten. Plan sessies bij voorkeur in dezelfde week; hoe langer de tijd tussen werven en testen, hoe hoger het percentage no-shows.
De meest gemaakte fout bij het script is taken opschrijven als instructies: "Klik op Instellingen, ga naar Meldingen en wijzig je voorkeur naar..." Daarmee vertel je de gebruiker wat hij moet doen, en test je dus of hij aanwijzingen kan opvolgen en niet of de interface intuïtief is.
Schrijf taken in plaats daarvan als scenario's: "Stel je voor dat je te veel meldingen krijgt en alleen een melding wilt ontvangen wanneer iemand je rechtstreeks noemt. Laat me zien wat je zou doen." Zo krijgt de gebruiker een realistisch doel en zie je hoe diegene echt navigeert — ook waar hij of zij de weg kwijtraakt.
Het moeilijkste aan het modereren van een usabilitytest is de drang om te helpen weerstaan. Als een gebruiker in de war is, zegt je instinct dat je moet ingrijpen en moet laten zien waar hij moet klikken. Maar die verwarring zijn juist de data. Een gebruiker die worstelt, vertelt je dat er iets mis is met de interface — en zodra je ingrijpt, verlies je dat signaal.
Vraag gebruikers om tijdens de hele sessie hardop te denken: "Vertel gewoon wat je ziet en wat je denkt terwijl je bezig bent." Dat levert een continue stroom data op over hun mentale model. Noteer niet alleen fouten, maar ook aarzelingen — een gebruiker die drie seconden twijfelt voordat hij op de juiste knop klikt, heeft nog steeds een ontwerpprobleem blootgelegd, ook al lukte het uiteindelijk.
De synthesestap is waar de meeste waarde ontstaat — en waar de meeste teams bezuinigen. Ruwe aantekeningen van vijf sessies zijn nog geen bevindingen. Dat worden ze pas als je als team een debrief houdt, observaties per thema groepeert en ernstniveaus toekent.
Houd de debrief op dezelfde dag als de sessies, zolang de observaties vers zijn. Verdeel problemen in drie categorieën: kritiek (gebruikers konden de taak niet afronden), gemiddeld (gebruikers rondden de taak af, maar met veel moeite of fouten) en klein (frictie die afronding niet verhinderde). Kritieke problemen moeten voor de lancering worden opgelost. Gemiddelde problemen krijgen prioriteit in de volgende sprint. Kleine problemen gaan naar de backlog.
Zet de bevindingen op één pagina: de top drie van kritieke problemen, elk met bewijs van minstens twee deelnemers, en per probleem een voorstel voor een ontwerpwijziging. Alles wat meer ruimte nodig heeft, hoort in een apart document.