Ska du genomföra användningstest för att validera hypoteser är de i bästa fall waste. I sämsta fall riskerar du att välja bort fantastiska idéer.
Låt mig göra en sak klar innan vi börjar. Kvalitativa och kvantitativa metoder har båda sina rättmätiga platser i verktygslådan. Sluta inte med användningstest.
I slutet av 90-talet började Rolf Molich (Jakob Nielsens kompis) med sin CUE-serie. CUE står för Comparative Usability Evaluations. Nio team fick i uppgift att utvärdera olika webbplatser. De fick använda valfri UX-metod. Många valde användningstest, en del valde expertutvärderingar (sic).
Efter andra testet började man se en överraskande trend. Teamen rapporterade helt olika UX-problem
Efter andra testet (CUE-2) började man se en överraskande trend. Teamen rapporterade helt olika användningsproblem:
“The CUE-2 teams reported 310 different usability problems. The most frequently reported problem was reported by seven of the nine teams. Only six problems were reported by more than half of the teams, while 232 problems (75 percent) were reported only once.”
Hur allvarliga UX-problemen var visade sig också vara högst subjektivt:
“Many of the problems that were classified as “serious” were only reported by a single team. Even the tasks used by most or all teams produced very different results — around 70 percent of the findings for each of these common tasks were unique.”
Och så fortsatte det. I CUE-4, när en hotellsajt skulle utvärderas, jobbade 17 team med UX-utvärderingar. Totalt rapporterades 340 UX-problem. Bara nio (!) av dessa rapporterades av mer än hälften av teamen. När Molich svarade på en direkt fråga: “Hur kan team vara säkra på att de adresserar rätt UX-problem?”, tydliggjorde han:
“Det är väldigt enkelt. De kan inte vara säkra.”
Vad säger oss detta? Användningstest är långt ifrån vetenskapliga. Reliabiliteten är inte sällan under all kritik. De är subjektiva och svåra att genomföra. Men var beror det på?
- Test genomförs på personer som inte är representativa för målgruppen
- Resultaten måste tolkas — subjektivt av naturen
- Team testar sin egna design vilket kan styra både outcome och tolkning av data
- Test och intervjuer genomförs i orealistisk miljö. T.ex. ställs detaljerade frågor om vyer som användaren bara besöker en bråkdel av sekund
- För få personer testas för att få statistisk säkerhet i själva valideringen
- När det gäller frågor om krav är användare inte sällan dåliga på att analysera sitt (framtida) beteende
Även om du gör allt rätt blir det fel
Du ska “validera” din design eller hypotes. Säg att du gör allt rätt. Så vetenskapligt det går.
- Du lyckas hitta testpersoner som är representativa för målgruppen.
- Du låter ett annat team testa din design.
- Du förklarar kontexten för dem perfekt.
- De tolkar användarnas beteende klockrent — ser igenom framförallt intervjusvar men också beteende som verkar orealistiskt för riktiga situationer.
- Användarna är så nära “riktig” kontext som möjligt.
- De är inte stressade över situationen.
- Testuppgifter och intervjufrågor är realistiska och stör inte användningens flow.
- Frågor ställs inte i orealistiska miljöer, som att be en användare kommentera en vy hen tittar på under lång tid.
Du gör allt det här rätt.
Ändå kommer du inte kunna vara säker på om en hypotes håller eller ej. Du testar på för få användare för att vara säker. Resultatet blir statistiskt insignifikanta anekdoter.
Även om du skulle testa på 20 användare — vilket jag varit med om en (1) gång under min tjugoåriga karriär inom UX — kommer du ha en felmarginal på ±19% när du drar slutsatser om hela populationen. För att komma ner till ±10% felmarginal (allmänt ansett som absolut minimum i branschen — de flesta kör dock med ±5%) behöver du 71 användare. Vilket blir vansinnigt dyrt. Det händer liksom inte.
Jag säger absolut inte att du ska sluta med användningstest. Jag menar att användningstest är en dålig metod för att validera hypoteser. Användningstest är bra på mycket. Du kan identifiera användbarhetsproblem. Du kan upptäcka problem för helt andra saker än det du testar. Du kan förstå beteende när du tolkar data professionellt. Du kan få riktigt bra uppslag till hypoteser. Och det är hyfsat billigt. Men — och det här är viktigt — du kan inte se hur omfattande ett problem är. Eller om en hypotes håller. Om dina observationer gäller för alla.
Som någon skrev:
Med användningstest riskerar du att välja bort bra idéer
Jag vet inte hur många gånger en hypotes jag skickat på användningstest rapporterats som “användarna verkade inte gilla lösningen” av ansvarig testledare. Jag har fått tjatat för att genomföra A/B-test av hypotesen. I många fall genomföra egna test under radarn. Och data från dessa A/B-test — och uppföljningstest — visar inte sällan på helt annan verklig användning än vad som framkommit i användningstest.
Du vill veta om din hypotes håller eller ej. Ta min rekommendation. A/B-testa din hypotes istället för att användningstesta. Men bara om du har möjlighet. Och med möjlighet menar jag:
- Mätpunkter som är odiskutabla, ej öppna för tolkning.
- Mätpunkter som är lätta att statistiskt validera i optimerings- och analysverktyg. Lojalitet är exempel på svår mätpunkt att följa upp i ett A/B-test.
- Tillräckligt med trafikvolym.
- Rimlig kostnad för att genomföra test.
- Korta eller obefintliga förändringskurvor (har du långa måste du följa upp över tid för att validera)
- Kunskap om A/B-test i din närhet.
Det är hit jag tycker många ska sträva som UX:are. Du fantastiskt kreativa och metodstarka person som redan är haj på användningstest och andra kvalitativa metoder. Förstå skillnaden mellan anekdot och empiri.
Du har makt, så använd rätt ord
Och snälla, snälla med körsbär på toppen. Generalisera aldrig när du presenterar kvalitativ data. Säg inte “användarna” eller “dom” när du visar dina fina filmer eller din presentation (“De gillar den här ikonen framför den här” / Användarna förstår att man kan…”). Det du säger riskerar då att upplevas som kvantitativ bevisad sanning. Och ännu värre är såklart att etablera värderingar i sin dataframställning: “Vad kul att användarna gillade den nya funktionen”.
Säg så här istället:
“Just den här användaren (+ lägg till ev osäkerhet i metod och kontext, ex stressad användare) verkar gilla/använda/ogilla/inte förstå innehållet/funktionaliteten. Det betyder inte alls att vi vet att det är så för vår målgrupp. Det betyder att vi kanske är ett problem/en lösning på spåren. Frågan är om tillräckligt många har samma problem/skulle bete sig likadant. Vad är det minsta vi kan bygga för att ta reda på det, tror ni?”
Genomför du intervjuer eller användningstest för att undersöka drivkrafter och beteenden? Var noga med att också researcha (eller validera med experiment) marknad och potential kopplat till drivkraften. User research och market research. Annars riskerar du att skapa fantastiska lösningar som ingen använder. Det är slöseri med pengar. Offentliga som privata.
Sträva efter arkitektur, verktyg och kultur som gör det enkelt och billigt att A/B-testa. Få det här på plats. Använd sedan kvantitativ data som kunskap. Krama den ömt. Bli en ännu bättre designer och rädda sedan världen.
Fram tills dess, var mycket noggrann med att inte dra kvantitativa slutsatser om en större population än de som varit med i användningstestet.
Fluffig hund av y-a-n under CC BY-NC-ND 2.0
Inlägget publicerades ursprungligen på valtech.se 10 november 2016.