Brugbarheds-test har et ufortjent ry for at være dyrt og langsomt. Når folk hører "brugerundersøgelse", forestiller de sig et envejes spejl, en moderator med en clipboard og en to-ugers tidslinje. Denne version af test findes og har sine brugsmål – men det er ikke den version, som de fleste produktteams har mest brug for.
Den version, de fleste teams har brug for, er enklere: fem brugere, en Figma-prototype eller et staging-miljø, et videoopkald og 45 minutter per session. Når det gøres godt, viser det flertallet af alvorlige brugbarheds problemer, før de sendes ud. Når det gøres konsekvent – selv én gang per sprint – producerer det en sammensat forbedring i produktkvalitet, som ingen post-launch analytics kan kopiere.
Her er hvordan man kører det fra bunden.
Fem deltagere er det rigtige antal for de fleste brugbarheds-tests. Jakob Nielsen's forskning etablerede, at fem brugere afdækker omkring 85% af brugbarheds problemer, med faldende udbytte derefter. At køre tre sessioner med fem brugere på forskellige punkter i designprocessen er mere værdifuld end en session med femten.
Kriterierne for rekruttering er vigtigere end antallet. En brugbarheds-test med fem mennesker, der tæt svarer til dine målpersona, vil afdække rigtige problemer. En test med femten mennesker, der ikke svarer, vil generere støj. Definer to eller tre screeningskriterier – rolle, brugskontekst, teknisk komfortniveau – og hold fast ved dem.
Den hurtigste rekrutteringsrute for de fleste teams er at sende e-mail til eksisterende brugere, der har givet kontakttilladelse. Tilbyd et beskedent incitament – et 20 £ gavekort er tilstrækkeligt for en 45-minutters session. Sigter mod at planlægge sessioner inden for samme uge; jo længere tid mellem rekruttering og test, jo højere no-show rate.
Den mest almindelige script-fejl er at skrive opgaver som instruktioner: "Klik på Indstillinger, naviger derefter til Notifikationer og skift dine indstillinger til..." Dette fortæller brugeren hvad han skal gøre, hvilket betyder, at du tester, om han kan følge retninger, ikke om grænsefladen er intuitiv.
Skriv opgaver som scenarier i stedet: "Forestil dig, at du har fået for mange notifikationer, og du vil kun modtage advarsler, når nogen nævner dig direkte. Vis mig hvad du ville gøre." Dette giver brugeren et realistisk mål og lader dig iagttage, hvordan de faktisk navigerer – inklusive hvor de bliver forvirrede.
Den sværeste del af at moderere en brugbarheds-test er at modstå lysten til at hjælpe. Når en bruger er forvirret, siger enhver instinkt at springe ind og vise dem hvor man skal klikke. Men forvirringen er dataene. En bruger der kæmper fortæller dig noget er galt med grænsefladen – og i det øjeblik du griber ind, mister du signalet.
Bed brugere om at tænke højt gennem hele sessionen: "Mens du går, fortæl mig bare hvad du ser på og hvad du tænker." Dette producerer en kontinuerlig strøm af data om deres mentale model. Bemærk ikke bare fejl, men tøven – en bruger der pause i tre sekunder før at klikke den rigtige knap har stadig afdækket et designproblem, selvom de til sidst lykkedes.
Syntetiserings-trinnet er hvor de fleste værdier skabes – og hvor de fleste teams skærer hjørner. Rånotater fra fem sessioner er ikke resultater. De bliver resultater, når du debriefing som et team, grupperer observationer efter tema og tildeler alvorligheds-vurderinger.
Gør debriefer samme dag som sessionerne, mens observationerne er friske. Gruppér problemer i tre beholdere: kritisk (brugere kunne ikke fuldføre opgaven), moderat (brugere fuldførte opgaven, men med betydelig vanskelighed eller fejl) og mindre (friktion, der ikke forhindrede fuldførelse). Kritiske problemer skal løses før lancering. Moderate problemer skal prioriteres i næste sprint. Mindre problemer går i backlog.
Skriv resultater på en enkelt side: de tre bedste kritiske problemer, med bevis fra mindst to deltagere hver, og en foreslået designændring for hver. Alt der har brug for mere plads end det tilhører i et separat dokument.