Användbarhetstestning har ett oförtjänt rykte om sig att vara dyrt och långsamt. När folk hör ”användarforskning” ser de framför sig en enkelriktad spegel, en moderator med ett block och en tidsplan på två veckor. Den formen av testning finns och har sina användningsområden, men det är inte den form de flesta produktteam behöver för det mesta.
Den form de flesta team behöver är enklare: fem användare, en Figma-prototyp eller en staging-miljö, ett videosamtal och 45 minuter per session. Görs det bra avslöjar det merparten av de allvarliga användbarhetsproblemen innan produkten lanseras. Görs det regelbundet, även bara en gång per sprint, ger det en kumulativ förbättring av produktkvaliteten som ingen mängd analys efter lansering kan ersätta.
Så här genomför du det från grunden.
Fem deltagare är rätt antal för de flesta användbarhetstester. Jakob Nielsens forskning visade att fem användare avslöjar omkring 85 % av användbarhetsproblemen, med avtagande avkastning därefter. Att köra tre sessioner med fem användare vid olika punkter i designprocessen är mer värdefullt än en session med femton.
Rekryteringskriterierna är viktigare än antalet. Ett användbarhetstest med fem personer som nära motsvarar din målgrupp avslöjar verkliga problem. Ett test med femton personer som inte gör det ger bara brus. Definiera två eller tre urvalskriterier, till exempel roll, användningssammanhang och teknisk vana, och håll fast vid dem.
Den snabbaste rekryteringsvägen för de flesta team är att mejla befintliga användare som har gett tillåtelse att bli kontaktade. Erbjud en måttlig ersättning – ett presentkort på £20 räcker för en session på 45 minuter. Sikta på att boka sessionerna inom samma vecka; ju längre tid det går mellan rekrytering och test, desto högre blir andelen uteblivna.
Det vanligaste misstaget när man skriver manus är att formulera uppgifterna som instruktioner: ”Klicka på Inställningar, gå sedan till Aviseringar och ändra din inställning till …” Då talar du om för användaren vad hen ska göra, vilket innebär att du testar om hen kan följa anvisningar, inte om gränssnittet är intuitivt.
Skriv i stället uppgifterna som scenarier: ”Föreställ dig att du har fått för många aviseringar och bara vill få en avisering när någon nämner dig direkt. Visa mig vad du skulle göra.” Det ger användaren ett realistiskt mål och låter dig se hur hen faktiskt navigerar, inklusive var hen blir förvirrad.
Det svåraste när du modererar ett användbarhetstest är att motstå impulsen att hjälpa till. När en användare är förvirrad säger varje instinkt att du ska hoppa in och visa var hen ska klicka. Men förvirringen är själva datan. En användare som kämpar talar om att något är fel med gränssnittet, och i samma stund som du ingriper förlorar du signalen.
Be användarna tänka högt under hela sessionen: ”Berätta bara medan du går vad du tittar på och vad du tänker.” Det ger en kontinuerlig ström av data om deras mentala modell. Notera inte bara fel utan också tvekan: en användare som pausar i tre sekunder innan hen klickar på rätt knapp har ändå avslöjat ett designproblem, även om hen till slut lyckades.
Sammanställningen är där det mesta av värdet skapas, och där de flesta team slarvar. Råa anteckningar från fem sessioner är inte resultat. De blir resultat när ni går igenom dem tillsammans, grupperar observationerna efter tema och sätter en allvarlighetsgrad.
Gå igenom resultaten samma dag som sessionerna, medan observationerna är färska. Dela in problemen i tre grupper: kritiska (användarna kunde inte slutföra uppgiften), måttliga (användarna slutförde uppgiften men med betydande svårigheter eller fel) och små (friktion som inte hindrade användarna från att slutföra). Kritiska problem måste åtgärdas före lansering. Måttliga problem bör prioriteras i nästa sprint. Små problem hamnar i backloggen.
Sammanfatta resultaten på en enda sida: de tre mest kritiska problemen, med belägg från minst två deltagare vardera, och ett förslag på designändring för vart och ett. Allt som kräver mer utrymme än så hör hemma i ett separat dokument.