Användbarhetstestning har ett oförtjänt rykte för att vara dyrt och långsamt. När människor hör "användarforskning" bildar de sig "en spegelvägg, en moderator med en urklipp och en två-veckor tidsplan. Den versionen av testning finns och har sina användningar – men det är inte versionen de flesta produktteam behöver mest av tiden.
Versionen de flesta team behöver är enklare: fem användare, en Figma-prototyp eller en staging-miljö, ett videosamtal och 45 minuter per session. Gjort väl uppdagar detta merparten av allvarliga användbarhesproblem innan de skeppas. Gjort konsekvent – även en gång per sprint – producerar det en förenad förbättring i produktkvalitet som ingen mängd post-launch-analys kan upprepa.
Här är hur du kör det från början.
Fem deltagare är rätt antal för de flesta användbarhetstester. Jakob Nielsens forskning fastställde att fem användare avslöjar omkring 85% av användbarhetsproblemen, med minskade avkastningar efter det. Att köra tre sessioner om fem användare på olika designpunkter är mer värdefullt än en session med femton.
Kriterierna för rekrytering är viktigare än numret. Ett användbarhetstest med fem personer som nära matchar din målperson avslöjar verkliga problem. Ett test med femton personer som inte matchar kommer att generera brus. Definiera två eller tre screeningkriterier – roll, användningskontext, teknisk komforts nivå – och håll till dem.
Den snabbaste rekryteringsvägen för de flesta team är att e-postpost befintliga användare som har gett kontaktövervakning. Erbjud ett blygsamt incitament – ett 150 SEK gåvokort räcker för en 45-minuters session. Syfta till att schemalägga sessioner inom samma vecka; ju längre luckan mellan rekrytering och testning, desto högre no-show-rate.
Det vanligaste skriptmistaget är att skriva uppgifter som instruktioner: "Klicka på Inställningar, navigera sedan till Meddelanden och ändra dina preferenser till..." Det här säger användaren vad de ska göra, vilket betyder att du testar om de kan följa riktningar, inte om gränssnittet är intuitivt.
Skriv uppgifter som scenarier istället: "Föreställ dig att du har fått för många meddelanden och du vill bara få varningar när någon nämner dig direkt. Visa mig vad du skulle göra." Det här ger användaren ett realistiskt mål och låter dig observera hur de faktiskt navigerar – inklusive var de blir förvirrade.
Det svåraste när du modererar ett användbarhetstest är att motstå impulsen att hjälpa. När en användare är förvirrad säger instinkt att hoppa in och visa dem var de ska klicka. Men förvirringen är data. En förvirrad användare säger dig något är fel med gränssnittet – och när du greppar in förlorar du signalen.
Be användare att tänka högt under hela sessionen: "Precis när du går, berätta bara vad du tittar på och vad du tänker." Det här producerar en kontinuerlig dataström om deras mentala modell. Notera inte bara fel utan tvekan – en användare som pausar i tre sekunder innan du klickar rätt knapp har fortfarande avslöjat ett designproblem, även om de i slutändan lyckades.
Syntesesteget är där de flesta värde skapas – och där de flesta team skär hörn. Råa anteckningar från fem sessioner är inte fynd. De blir fynd när du debriefer som team, grupperar observationer efter tema och tilldelar allvarlighetsgraderingar.
Gör debriefingen samma dag som sessionerna, medan observationerna är färska. Gruppera problem i tre buckets: kritisk (användare kunde inte slutföra uppgiften), måttlig (användare slutförde uppgiften men med betydande svårighet eller fel) och mindre (friktion som inte förhindrade slutförande). Kritiska problem måste fixas innan lanseringen. Måttliga problem bör prioriteras nästa sprint. Mindre problem går i backloggen.
Skriv fynd på en enda sida: de tre topp-kritiska problemen, med bevis från minst två deltagare vardera, och en föreslagen designändring för varje. Allt som behöver mer utrymme än det tillhör ett separat dokument.