Stäng Huvudmeny

Varför det är nonsens att bara testa med 5 användare (om du inte ställer rätt frågor)

Användningstester & Eyetracking

Hej du främmande människa på internet, ledsen för ”clickbait”-titeln, men jag måste ta upp något jobbigt med dig… Nånting som hugger till i magen varje gång jag ser det. Sluta göra puckade saker med dina användningstest!

Användningstester är en metod för att testa din sajt eller produkt mot din målgrupp, där du ber ett urval personer använda och testa t.ex. en del av ett flöde. Du kan utifrån testresultat identifiera problem – Hur många testpersoner du använder är intressant men beror på 1) Vilka frågor du ställer testpersonerna och 2) Vilka slutsatser du tar givet deras svar. DET ska vi beröra i denna post.

Användningstestning och eyetracking är väldigt användbara verktyg när man optimerar en hemsida. Likt många andra verktyg kan de användas på olika sätt för olika problem, men de är trots det värdelösa för vissa uppgifter. Det var jättebra att ha en hammare när jag snickrade på min trädkoja som ett barn, men den var betydligt mindre användbar när jag sparkat en fotboll genom pappas fönster.

Det stora missförståndet om antalet användare vid ett test

Jag har många gånger hört personer referera till den berömda Nielsen Norman- och Tom Landauer-studien, samtidigt som de helt missar poängen studien försöker få fram.
Graf som visar avtagande fördelar med ökat antalet testpersoner som visades i studien 1993
Studien visar att små grupper testpersoner är ett effektivt sätt att hitta exempel på användbarhetsproblem, det betyder inte att fem användare är tillräckligt för alla forskningsfrågor.

När man pratar om 5 användare, så måste resultatet analyseras kvalitativt inte kvantitativt. Trots detta drar både personer som får resultaten och de som genomför testen felaktiga (kvalitativa slutsatser)

Kvalitativ: data används ofta för explorativa undersökningar, där man upptäcker beteenden och deras bakomliggande anledningar med hjälp av mindre grupper användare.

Kvantitativ: data aggregeras från större urval och används för att ta reda på ur ofta någon inträffar. T.ex. hur stor andel av användarna som lämnar besöket i checkout.

Hur skall vi hantera data från test med få användare?

Användningstest med få testpersoner är ett bra och resurseffektivt sätt att få insikter på. De kan användas som en iterativ del av designprocessen, som en del av kontinuerlig optimering för att ge bättre förståelse av möjliga beteenden eller för att upptäcka användbarhetsproblem som inte fångats tidigare. Så det är inte problematiskt att göra användningstester med 5 personer, det är som regel ett bra sätt att göra det på, så länge du inte vill veta hur ofta något händer.

Men, men, men om 4 av 5 gjorde en sak så måste det ju betyda något

Sekunden någon försöker hävda att något är ett vanligt beteende baserat på hur många av den lilla gruppen testpersoner som gjorde det, så har de gått utanför sin valda analysmetod.

Vanligtvis får jag svaret ”Men, men, men om 4 av 5 gjorde en sak så måste det ju betyda något”. Visst, det stämmer att chansen är högre att beteendet är vanligt, men gruppen är så liten att variationen fortfarande är stor. Kasta en tärning 5 gånger och försök använda det resulterade datasetet för att fastställa hur vanligt det är att tärningar landar på olika sidor… inte en särskilt bra metod eller hur? Eftersom vi människor är dåliga på att hantera osäkerhet, så brukar folk tolka 4 av 5 påståenden som att ett beteende vore normen snarare än att tolka det korrekt utifrån urvalsstorleken ”det är lite mer troligt att det här beteendet är normen än att de inte är det”

När jag har kommit så här långt i en diskussion om detta ämne så brukar en av två frågor dyka upp.

Om jag inte får svar på hur vanligt något är så är användningstestning meningslöst!

eller

Men det här gäller inte oss, vi testar med 8 eller 10 eller nått annat antal användare!

Låt oss svara på dessa en i taget

”Om jag inte får svar på hur vanligt något är så är användningstestning meningslöst!”

Visst vi kan inte extrapolera hur vanligt ett beteende är för en liten grupp testpersoner och hoppas att de skall vara representativt för hela våran besökarskara. Men inget hindrar oss från att resonera kring de upptäckta beteendet och vilka implikationer de har, samtidigt som det är fullt möjligt att dubbelkolla de identifierade beteendet i andra kvantitativa källor om det behövs för att kunna fatta ett beslut.Var inte den som använder hammaren för varje jobb, använd den där det passar

Scenario:

Om vi genomför ett test och märker att vissa användare har problem med ifyllandet av ett obligatoriskt fält i ett formulär (t.ex. om de bara accepterar 12-siffriga personnummer, utan att ge användaren någon instruktion eller hjälp). Det är bra att ha koll på även om vi inte vet hur vanligt det är med felinmatningar. Det är definitivt något vi skall ta tag i eftersom det kan frustrera användare eller till och med hindra dem från att genomföra sitt köp. Dessutom skulle de logiska förbättringarna troligtvis vara utan negativa effekter för besökaren så vi kan lägga till upptäckten till vår ”to do list” med förbättringar från testet.

Snabblösning:

För att snabbt adressera problemet lägger vi in hjälpande text i anslutning till fältet. Men vi vill ha så låg friktion som möjligt i formuläret, så vi skulle vilja ändra logiken bakom fältet så att de kan ta alla input-former och sen transformera dem till rätt format för vår databas. Men som vanligt så är utvecklartid tight, så vi vill fastställa att förändringen kommer hjälpa många användare.

Djupdykning:

Vi vet att fältet är obligatoriskt så potentialen finns att förbättra upplevelsen för många användare, men vi vet inte hur stor andel av våra besökare som föredrar ett ”felaktigt” input-format.

Vi skulle kunna försöka hitta generell statistik för hur ofta olika format används, men troligtvis har vi ett ännu bättre alternativ tillgängligt i form av vår egen kvantitativa webbanalys data t.ex. genom felmeddelande-tracking i google analytics.

När vi väl vet vad vi letar efter så är det enkelt att hitta i Google Analytics (eller så hittar vi brister i vår tracking) och vi är redo att prioritera in det i vår dev-backlog Insikter från användningstester kan sträcka sig från saker som bara är att göra rakt av, till insikter som blir en hypotes som slutgiltigt valideras via ett A/B-test.
Varför ett A/B-test? Helt enkelt för att det finns både för och nackdelar kopplade till agerandet på våra insikter från användningstestet, så vi behövde mäta effekten på våra besökare i större skala.

Oavsett vad så var användningstestet inte meningslöst, de drog vår uppmärksamhet till något och gav oss djupare förståelse av det och dess möjliga orsaker. Beroende på vad vi hittade tog vi det bara vidare på olika sätt..

”Men det här gäller inte oss, vi testar med 8 eller 10 eller nått annat antal användare!”

Man måste ha ganska stort antal testpersoner och ha väldigt tydliga trender i beteende för att kunna dra kvantitativa slutsatser som är valida. Det är möjligt att genomföra i större projekt men det tar ordentligt mycket mer än 10 användare och om du vill testa på det sättet för att få kvantitativa svar så borde du försäkra dig om att du inte slösar resurser genom att få findings som vore bättre att inhämta med en annan metodik.

Med det sagt, så kan jag tillägga att vi testar med varierande antal testpersoner hela tiden. Det är dock sällan som vi gör det för att vi vill nå antal där vi kan börja aggregera resultaten för att hantera datan kvantitativt.

Så varför varierar vi antalet försöksanvändare då? För att öka sannolikheten att stöta på olika typer av beteende. Är en stor tidigare otestad funktion på väg att gå live samtidigt som vi bara har ett test på oss att identifiera och fixa problem innan den går live? Ja då vill försäkra oss om att risken att missa viktiga findings är låg, så vi vill ha många testpersoner. Fast du kanske följer en bättre modell för att utveckla och släppa nya funktioner…

Om vi genomför iterativ testning från början av ett test? Ja då är 5 personer ett tillräckligt antal som håller effektiviteten i testningen hög, samtidigt som vi har flera tester på oss att fånga något som kanske inte uppmärksammas under ett tidigare test. Slutligen så kanske du specifikt gör ett test i syfte att undersöka ett ovanligt beteende? Då behöver vi ju öka antalet testpersoner för att ha en rimlig chans att stöta på exempel av det vi letar efter.

Tabell visande sannolikheten att stöta på åtminstone en instans av ett beteende under ett test, som en funktion av antalet testpersoner och sannolikheten att stöta på beteendet per person.Sannolikheten att stöta på åtminstone en instans av ett beteende under ett test, baserat på antalet testpersoner och sannolikhet för det beteendet att uppstå per användare.

Det är helt enkel bra att variera antalet testpersoner baserat på vad du gör för studie, men om du är ute efter att besvara kvalitativa frågor med ditt test så borde du försäkra dig om att det inte finns en annan datainsamlingsmetod som bättre uppfyller dina behov.

Slutsats

Om du bara har en hammare, ser allt ut som spikar. Användningstester är ett bra och effektivt sätt att bygga förståelse för hur användare interaktioner med din sida kan se ut. Men använd det inte för att besvara alla typer av frågor om du har bättre verktyg tillgängliga.

Internet är fantastiskt för att insamla användningsdata Vi har en uppsjö av olika källor tillgängliga och det är lättare än aldrig förr att få bra kvantitativ data. Därför är användningstestning sällan rätt verktyg för att svara på hur vanligt ett beteende är (även om folk som bara har användningstestning som verktyg kanske tycker att det är toppen att säga att 4 av 5 gjorde något.

Så fort du hör någon säga den typen av nummer i en presentation, eller om du funderar på att säga det själv, stanna och fundera på vad som är det riktiga antalet: Var det 80 av 100, 40 av 50 eller helt enkelt 4 av 5. Risken finns att det är fel svar på fel fråga, istället borde fokusen ligga på vad och varför det hände. Varför är ju där styrkan med användningstester verkligen ligger, hur ofta borde oftast besvaras i din webbanalysdata.


Patrik Matell Om Patrik

Patrik har akademisk grundplatta inom Datalogi och Människa-Datorinteraktion. Internet är hans lekplats sedan barnsben. Konvertering låg varmt om hjärtat från start, idag med en kryddning av Användartester i allmänhet och Eyetracking i synnerhet.

  • Conversionista fortsätter leverera hög kvalitet. Tack Patrik

    • Kul att du uppskattar den!
      Jag har känt ett behov av att adressera ämnet ett bra tag nu.

Få gratis konverteringstips

Anmäl dig till vårt nyhetsbrev

Nyhetsbrev

Lär av…

Kundcase Mathem ✻ Guldkorn
✻ Mallar och metoder
✻ A/B-tester och resultat
Lär av case

Kan du göra lika?

Se kundcase Se kundcase✔︎ Analys & webbpsykologi
✔︎ A/B-tester & resultat
Se alla case

Få platser kvar till flera seminarier

Anmäl dig till seminarium ✔︎ Webbpsykologi & verktyg
✔︎ A/B-testning & Google 360
✔︎ Snacka med experterna

Flera tillfällen i vinter

Säkra din plats

Spara 1000 kr

Conversion Jam 2017

Missade du?

Världens största CRO-event

Spara 1000 kr på din biljett till CJAM8

Du, kontakta oss!

Kontakta oss
Gitte eller hennes awesome kollegor hjälper dig.