Brukbarhetstesting har et ufortjent rykte for å være dyrt og langsomt. Når folk hører "brukerundersøkelser", bilder de seg et enveisbilde, en moderator med en notisblokk, og en to ukers tidslinje. Den versjonen av testing finnes og har sine bruksområder — men det er ikke versjonen de fleste produktteam trenger mest av tiden.
Versjonen de fleste team trenger er enklere: fem brukere, en Figma-prototype eller et fasingstage-miljø, en videosamtale, og 45 minutter per sesjon. Gjort godt, avdekker dette flertallet av alvorlige brukbarhetsproblemet før de sendes. Gjort konsekvent — selv en gang per sprint — produserer det en sammensatt forbedring i produktkvalitet som ingen mengde post-launch-analyser kan gjenskape.
Her er hvordan du kjører det fra bunnen.
Fem deltakere er riktig nummer for de fleste brukbarhetstest. Jakob Nielsens forskning etablerte at fem brukere avdekker rundt 85 % av brukbarhetsproblemer, med minkende avkastning etter det. Å kjøre tre sesjoner med fem brukere på ulike punkter i designprosessen er mer verdifullt enn en sesjon med femten.
Kriteriene for rekruttering er viktigere enn tallet. En brukbarhetstest med fem personer som nøye matcher din målbruker vil avdekke reelle problemer. En test med femten personer som ikke matcher vil generere støy. Definer to eller tre screeningskriterier — rolle, brukskontekst, teknisk komfortnivå — og hold deg til dem.
Den raskeste rekrutteringsruten for de fleste team er å e-poste eksisterende brukere som har gitt kontakttillatelse. Tilby et moderat insentiv — et gavekort på 20 pund er nok til en 45-minutters sesjon. Siktemål å planlegge sesjoner innen samme uke; jo lengre tid mellom rekruttering og testing, jo høyere no-show-rate.
Den vanligste skriptfeilen er å skrive oppgaver som instruksjoner: "Klikk på Innstillinger, deretter naviger til Varsler, og endre innstillingen til..." Dette forteller brukeren hva de skal gjøre, noe som betyr at du tester om de kan følge retninger, ikke om grensesnittet er intuitivt.
Skriv oppgaver som scenarier i stedet: "Tenk at du har fått for mange varsler og du vil bare motta varsler når noen nevner deg direkte. Vis meg hva du ville gjøre." Dette gir brukeren et realistisk mål og lar deg observere hvordan de faktisk navigerer — inkludert hvor de blir forvirret.
Den vanskeligste delen av moderering av en brukbarhetstest er å motstå impulsen til å hjelpe. Når en bruker er forvirret, sier hver instinkt at du skal hoppe inn og vise dem hvor de skal klikke. Men forvirringen er dataene. En bruker som sliter forteller deg noe er galt med grensesnittet — og øyeblikket du griper inn, mister du signalet.
Be brukere tenke høyt gjennom sesjonen: "Når du går, fortell bare hva du ser og hva du tenker." Dette produserer en kontinuerlig strøm av data om deres mentale modell. Noter ikke bare feil, men nøling — en bruker som pauser i tre sekunder før de klikker på knappen riktig, har fortsatt avdekket et designproblem, selv om de til slutt lyktes.
Syntesestrinnet er hvor det meste av verdien blir opprettet — og hvor de fleste team kutter hjørner. Rånotater fra fem sesjoner er ikke funn. De blir funn når du debriefer som et team, grupperer observasjoner etter tema, og tilordner alvorlighetsgrader.
Gjør debrieringen samme dag som sesjonene, mens observasjonene er ferske. Grupper problemer i tre sekker: kritisk (brukere kunne ikke fullføre oppgaven), moderat (brukere fullførte oppgaven men med betydelig vanskelighet eller feil), og mindre (friksjon som ikke forhindret fullføring). Kritiske problemer må fikses før lansering. Moderate problemer bør prioriteres i neste sprint. Mindre problemer går i backloggen.
Skriv funn på en enkelt side: de tre øverste kritiske problemene, med bevis fra minst to deltakere hver, og en foreslått designendring for hver. Alt som trenger mer plass enn det, tilhører et eget dokument.