Brukertesting har et uforskyldt rykte på seg for å være dyrt og tidkrevende. Når folk hører «brukerundersøkelser», ser de for seg et observasjonsrom med enveisspeil, en moderator med notatblokk og en tidsplan på to uker. Den typen testing finnes og har sine bruksområder – men det er ikke den typen de fleste produktteam trenger mesteparten av tiden.
Den typen de fleste team trenger, er enklere: fem brukere, en Figma-prototype eller et testmiljø, en videosamtale og 45 minutter per økt. Gjort godt avdekker dette de fleste alvorlige brukervennlighetsproblemene før de når ut til brukerne. Gjort jevnlig – selv bare én gang per sprint – gir det en forbedring av produktkvaliteten som bygger seg opp over tid, og som ingen mengde analyse etter lansering kan måle seg med.
Slik gjennomfører du det fra bunnen av.
Fem deltakere er riktig antall for de fleste brukertester. Jakob Nielsens forskning viste at fem brukere avdekker rundt 85 % av brukervennlighetsproblemene, og at nytten avtar etter det. Å gjennomføre tre runder med fem brukere på ulike tidspunkter i designprosessen er mer verdifullt enn én runde med femten.
Kriteriene for rekruttering er viktigere enn antallet. En brukertest med fem personer som ligner mye på målbrukeren din, vil avdekke reelle problemer. En test med femten personer som ikke gjør det, vil gi bare støy. Definer to eller tre utvelgelseskriterier – rolle, brukskontekst, teknisk trygghet – og hold deg til dem.
Den raskeste veien til deltakere for de fleste team er å sende e-post til eksisterende brukere som har gitt tillatelse til å bli kontaktet. Tilby en beskjeden godtgjørelse – et gavekort på 20 pund holder for en økt på 45 minutter. Sikt på å legge øktene innenfor samme uke; jo lengre tid det går mellom rekruttering og testing, desto flere uteblir.
Den vanligste feilen når man skriver manus, er å formulere oppgaver som instruksjoner: «Klikk på Innstillinger, gå til Varsler og endre preferansen din til …» Da forteller du brukeren hva vedkommende skal gjøre, og dermed tester du om brukeren kan følge anvisninger, ikke om grensesnittet er intuitivt.
Skriv heller oppgavene som scenarioer: «Tenk deg at du har fått for mange varsler og bare vil motta varsler når noen nevner deg direkte. Vis meg hva du ville gjort.» Det gir brukeren et realistisk mål og lar deg observere hvordan vedkommende faktisk navigerer – inkludert hvor det blir forvirrende.
Det vanskeligste når du leder en brukertest, er å motstå trangen til å hjelpe. Når en bruker er forvirret, sier alle instinkter at du bør gripe inn og vise hvor vedkommende skal klikke. Men forvirringen er dataene. En bruker som sliter, forteller deg at noe er galt med grensesnittet – og i det øyeblikket du griper inn, mister du signalet.
Be brukerne tenke høyt underveis: «Fortell meg bare hva du ser på og hva du tenker mens du går.» Det gir en jevn strøm av data om den mentale modellen deres. Noter ikke bare feil, men også nøling – en bruker som stopper i tre sekunder før vedkommende klikker på riktig knapp, har likevel avslørt et designproblem, selv om det til slutt gikk bra.
Det er i oppsummeringen mesteparten av verdien skapes – og der de fleste team tar snarveier. Rånotater fra fem økter er ikke funn. De blir funn når dere går gjennom dem som team, grupperer observasjonene etter tema og vurderer alvorlighetsgrad.
Gjør oppsummeringen samme dag som øktene, mens observasjonene er ferske. Grupper problemene i tre kategorier: kritisk (brukerne klarte ikke å fullføre oppgaven), moderat (brukerne fullførte oppgaven, men med store vanskeligheter eller feil) og liten (friksjon som ikke hindret at oppgaven ble fullført). Kritiske problemer må løses før lansering. Moderate problemer bør prioriteres i neste sprint. Små problemer havner i backloggen.
Skriv ned funnene på én side: de tre viktigste kritiske problemene, med belegg fra minst to deltakere for hvert, og et forslag til designendring for hvert. Alt som trenger mer plass enn det, hører hjemme i et eget dokument.