Usability testing heeft een onverdiende reputatie voor duur en traag zijn. Wanneer mensen "user research" horen, stellen zij zich voor: een eenrichtingsspiegel, een moderator met een klembord, en een tijdlijn van twee weken. Die versie van testing bestaat en heeft zijn toepassingen — maar het is niet de versie die de meeste productteams het meeste nodig hebben.
De versie die de meeste teams nodig hebben is eenvoudiger: vijf gebruikers, een Figma-prototype of een staging-omgeving, een videogesprek, en 45 minuten per sessie. Goed gedaan, dit oppervlakt het merendeel van ernstige usability-problemen voordat zij worden uitgebracht. Consistent gedaan — zelfs eenmaal per sprint — het produceert een samengestelde verbetering in productkwaliteit die geen hoeveelheid post-launch analytics kan repliceren.
Hier is hoe je het helemaal opnieuw kunt uitvoeren.
Vijf deelnemers is het juiste aantal voor de meeste usability tests. Het onderzoek van Jakob Nielsen stelde vast dat vijf gebruikers ongeveer 85% van usability-problemen oppervlakken, met afnemende voordelen daarna. Het uitvoeren van drie sessies van vijf gebruikers op verschillende punten in het ontwerpproces is waardevoller dan één sessie met vijftien.
De criteria voor rekrutering zijn belangrijker dan het aantal. Een usability test met vijf personen die nauw aansluiten bij je doelgebruiker zal echte problemen onthullen. Een test met vijftien personen die niet aansluiten zal ruis genereren. Definieer twee of drie screeningcriteria — rol, gebruikscontext, technisch comfortniveau — en houd eraan vast.
De snelste recruteringsroute voor de meeste teams is het e-mailen van bestaande gebruikers die contacttoestemming hebben gegeven. Bied een bescheiden incentive — een £20 geschenkkaart is voldoende voor een 45-minuutse sessie. Streven naar het plannen van sessies binnen dezelfde week; hoe langer het gat tussen rekrutering en testing, hoe hoger het no-show-tarief.
De meest voorkomende scripting-fout is het schrijven van taken als instructies: "Klik op Instellingen, navigeer vervolgens naar Meldingen en wijzig je voorkeur in..." Dit vertelt de gebruiker wat hij moet doen, wat betekent dat je test of hij aanwijzingen kan volgen, niet of de interface intuïtief is.
Schrijf in plaats daarvan taken als scenario's: "Stel je voor dat je teveel meldingen krijgt en alleen meldingen wilt ontvangen wanneer iemand je rechtstreeks noemt. Laat me zien wat je zou doen." Dit geeft de gebruiker een realistisch doel en laat je zien hoe zij daadwerkelijk navigeren — inclusief waar zij verward raken.
Het moeilijkste deel van het modereren van een usability test is het weerstaan van de drang om te helpen. Wanneer een gebruiker in verwarring is, zegt elk instinct je om in te springen en hun te laten zien waar ze moeten klikken. Maar de verwarring is de gegevens. Een gebruiker die worstelt vertelt je dat er iets mis is met de interface — en op het moment dat je interveniërt, verlies je het signaal.
Vraag gebruikers om hardop te denken gedurende de hele sessie: "Terwijl je gaat, vertel me gewoon wat je ziet en wat je denkt." Dit produceert een continue stroom gegevens over hun mentale model. Noteer niet alleen fouten, maar aarzeling — een gebruiker die drie seconden aarzelt voordat hij op de juiste knop klikt, heeft nog steeds een ontwerpprobleem onthult, zelfs als hij uiteindelijk slaagde.
De synthesisatiestap is waar het meeste van de waarde wordt gegenereerd — en waar de meeste teams hoeken afsnijden. Ruwe aantekeningen van vijf sessies zijn geen bevindingen. Zij worden bevindingen wanneer je als team debrieft, waarnemingen op thema groepeert, en ernstniveaus toewijst.
Doe de debriefing op dezelfde dag als de sessies, terwijl de waarnemingen nog vers zijn. Groepeer problemen in drie buckets: kritiek (gebruikers konden de taak niet voltooien), gemiddeld (gebruikers voltooiden de taak maar met aanzienlijke moeite of fout), en minor (wrijving die voltooiing niet verhinderde). Kritieke problemen moeten voor lancering opgelost worden. Gemiddelde problemen moeten in de volgende sprint prioritair worden gesteld. Minor-problemen gaan naar de backlog.
Schrijf bevindingen op in één pagina: de top drie kritieke problemen, met bewijs van ten minste twee deelnemers elk, en een voorgestelde ontwerpwijziging voor elk. Alles wat meer ruimte dan dat nodig heeft, hoort in een apart document.