
Brugervenlighedstest har et uretfærdigt ry for at være dyre og langsomme. Når folk hører »brugerundersøgelse«, ser de et envejsspejl for sig, en moderator med en notesblok og en tidsplan på to uger. Den slags test findes og har sine anvendelser, men det er ikke den form, de fleste produktteams har brug for de fleste gange.
Den form, de fleste teams har brug for, er enklere: fem brugere, en Figma-prototype eller et staging-miljø, et videomøde og 45 minutter pr. session. Når det gøres godt, afslører det størstedelen af de alvorlige brugervenlighedsproblemer, før produktet udkommer. Når det gøres jævnligt, selv blot én gang pr. sprint, giver det en forbedring af produktkvaliteten, der bygger oven på sig selv, og som ingen analyser efter lanceringen kan matche.
Sådan kører du det fra bunden.
Fem deltagere er det rigtige antal til de fleste brugervenlighedstests. Jakob Nielsens forskning har vist, at fem brugere afdækker omkring 85 % af brugervenlighedsproblemerne, og at udbyttet derefter aftager. Tre sessioner med fem brugere på forskellige tidspunkter i designprocessen er mere værd end én session med femten.
Rekrutteringskriterierne er vigtigere end antallet. En brugervenlighedstest med fem personer, der ligner din målgruppe, vil afsløre reelle problemer. En test med femten personer, der ikke gør, giver bare støj. Fastlæg to eller tre screeningskriterier, fx rolle, brugssammenhæng og teknisk fortrolighed, og hold fast i dem.
Den hurtigste vej til rekruttering for de fleste teams er at skrive til eksisterende brugere, der har givet tilladelse til at blive kontaktet. Tilbyd et beskedent incitament; et gavekort på 20 £ er nok til en session på 45 minutter. Sigt efter at lægge sessionerne inden for samme uge, for jo længere der går mellem rekruttering og test, jo flere udeblivelser får du.
Den hyppigste fejl i drejebogen er at skrive opgaver som instruktioner: »Klik på Indstillinger, gå til Notifikationer, og skift din indstilling til ...« Det fortæller brugeren, hvad vedkommende skal gøre, så du tester, om brugeren kan følge anvisninger, og ikke om brugerfladen er intuitiv.
Skriv i stedet opgaverne som scenarier: »Forestil dig, at du får for mange notifikationer, og at du kun vil have besked, når nogen nævner dig direkte. Vis mig, hvad du ville gøre.« Det giver brugeren et realistisk mål og lader dig se, hvordan vedkommende rent faktisk navigerer, også hvor vedkommende bliver forvirret.
Det sværeste ved at moderere en brugervenlighedstest er at lade være med at hjælpe. Når en bruger er forvirret, siger alle instinkter, at du skal gribe ind og vise, hvor der skal klikkes. Men forvirringen er netop data. En bruger, der slås med brugerfladen, fortæller dig, at noget er galt, og i det øjeblik du griber ind, mister du signalet.
Bed brugerne om at tænke højt under hele sessionen: »Fortæl mig undervejs, hvad du kigger på, og hvad du tænker.« Det giver en løbende strøm af data om deres mentale model. Notér ikke kun fejl, men også tøven. En bruger, der holder pause i tre sekunder, før vedkommende klikker på den rigtige knap, har stadig afsløret et designproblem, selv om vedkommende til sidst klarede det.
Det er i opsamlingen, den meste værdi skabes, og det er her, de fleste teams skærer hjørner. Rå noter fra fem sessioner er ikke resultater. De bliver til resultater, når I holder debriefing som team, grupperer observationerne efter tema og giver dem en alvorlighedsgrad.
Hold debriefing samme dag som sessionerne, mens observationerne er friske. Gruppér problemerne i tre kasser: kritisk (brugerne kunne ikke gennemføre opgaven), moderat (brugerne gennemførte opgaven, men med betydelige vanskeligheder eller fejl) og mindre (gnidninger, der ikke forhindrede gennemførelsen). Kritiske problemer skal rettes før lanceringen. Moderate problemer bør prioriteres i næste sprint. Mindre problemer kommer i backloggen.
Skriv resultaterne ned på én side: de tre vigtigste kritiske problemer, hver med belæg fra mindst to deltagere, og et forslag til en designændring for hvert. Alt, der kræver mere plads end det, hører til i et separat dokument.