Sju vanliga misstag vid användningstestning
Fritt översatt från:
Seven Common Usability Testing Mistakes - UX Articles by Center Centre
Vad är det enklaste sättet att genomföra ett användbarhetstest? Tja, du kan bara sätta en person (det spelar ingen roll vem) framför din design och be dem att göra något (det spelar ingen roll vad).
Om detta är så enkelt, varför innehåller då ett standardtest för användbarhet allt det där andra krånglet? Eftersom den rigmarolen går långt för att säkerställa att testet kommer att ge kvalitetsresultat.
Arbeta för välgrundade beslut
När en design har ett användbarhetsproblem beror det på att någon har fattat ett felaktigt beslut. De valde att ta designen i en riktning som skapar frustration för användaren. Ett annat designval skulle ha förhindrat frustrationen.
Vi anser att ett användbarhetstest är framgångsrikt när designteamets medlemmar får den information de behöver för att fatta rätt beslut. Framgångsrika användbarhetstester ger välgrundade beslut.
Det finns två resultat av dåliga beslut: antingen försämras användarupplevelsen på grund av en förändring som helt enkelt inte borde ha hänt; eller så missas en värdefull möjlighet att förbättra designens användarupplevelse. Hur som helst, när användbarhetstester fungerar är dessa resultat betydligt mindre sannolika.
När vi arbetar med team över hela världen finns det misstag som vi ofta ser. Dessa misstag är mycket lätta att förhindra – om bara teammedlemmarna insåg att de gjorde dem. Här är sju av de vanligaste misstagen:
Misstag #1: Vet du varför du testar?
Det första misstaget vi ständigt ser är att team inte förstår när användbarhetstestning kan hjälpa och när det inte kan det. Användbarhetstestning är ett verktyg för att producera information. Det kan dock inte effektivt producera alla typer av information.
Dessa team gör ofta misstaget att använda användbarhetstester för att se hur användarna "känner" för designen. De vill veta om de testade deltagarna kommer att föredra designen, vill använda den igen och dela den med sina vänner.
Även om allt detta är viktiga saker att ta reda på, är ett standardtest av användbarhet inte rätt sätt att göra det på. Vi har sett fall där användare var extremt frustrerade över designen – inte kunde slutföra en enda uppgift – men berättade för oss att de älskade den. Vi har också kommit ut ur tester där användarna slutförde varje uppgift snabbt och effektivt, men hatade designen, även om de också sa att de skulle använda den igen. Det är väldigt svårt att veta vad man ska ändra på när man får resultat som dessa.
Eftersom ett användbarhetstest gör det möjligt för dig att observera användarens faktiska beteende, är dess verkliga styrka att berätta var gränssnittet orsakar frustration. Observationen av hur användarna flödar genom designen ger mycket mer användbar information än att fråga dem om de gillar det eller inte.
Du kan undvika detta första misstag genom att vara tydlig med vad du vill få ut av testet. Att ställa en beteendefråga eller två, till exempel "Kan våra användare ansöka om ett bolån utan förvirring?" eller "Kommer innehållet att minska samtalen till vårt supportcenter?", kommer att dramatiskt förbättra de testresultat du får. Ju mer detaljerad frågan är, desto bättre blir dina resultat. Du vet när designen fungerar och vad du ska göra om den inte gör det.
Misstag #2: Att inte föra samman teamet
När du gick i grundskolan, spelade du någonsin telefonspelet? Det är spelet där någon viskar ett talesätt (som "Anden är villig, men köttet är svagt") i en persons öra, som sedan viskar det till nästa person, och så vidare; där den sista personen säger högt vad de hört ("Köttet har blivit dåligt, men vinet smakar ganska bra").
När människor vidarebefordrar information till varandra blir den föremål för förvrängning, ungefär som telefonspelet. Det är precis vad som händer när användbarhetstestning utförs som en extern aktivitet, där teammedlemmarna knappt är uppmärksamma.
De mest framgångsrika testerna beror på att teamet är involverat i varje steg i processen. De tittar på varje test och absorberar informationen så snabbt den kommer, utan den naturliga filtrering och förvrängning som uppstår när de måste höra resultaten i andra eller tredje hand.
Att undvika detta misstag är enkelt: se bara till att teamet är engagerat. Vi har kommit fram till att detta innebär att göra testerna så nära teamet som möjligt (t.ex. ett lokalt konferensrum) och att ge incitament för att delta (mat fungerar alltid). Även när en teammedlem inte kan delta i ett specifikt test bör det vara lätt för dem att se videon eller få en detaljerad sammanfattning av vad som hände.
Misstag #3: Att inte rekrytera rätt deltagare
Användbarhetstestning handlar om att se designen genom testdeltagarnas ögon. När de arbetar sig igenom designen får du se och höra vad som fungerar bra och var det blir frustrerande att uppnå deras mål.
Men om du har rekryterat fel deltagare kommer du inte att lära dig vad du vill ha. Om deltagaren vet för mycket kommer han eller hon inte att uppleva de problem som riktiga användare kommer att stöta på. Om de inte har tillräckligt med rätt upplevelse kommer de att fastna med saker som dina användare kommer att flyga förbi.
Ett vanligt misstag är att fokusera på demografi (t.ex. ålder och inkomst) och inte titta på de skillnader som gör att användarna beter sig olika, t.ex. deras flyt i designens innehållsområde. Risken är att du missar kritiska problem som är lätta att åtgärda, bara för att de deltagare du rekryterat inte råkade stöta på dem.
När du planerar vem du ska rekrytera är den bästa tekniken att börja med att fråga: "Vilka egenskaper kommer att få en användare att bete sig annorlunda än en annan?" Detta kan ofta fokusera rekryteringsprocessen på att hitta personer som matchar användarna extremt bra och på så sätt förbättra kvaliteten på testresultaten.
Misstag #4: Att inte utforma rätt uppgifter
För flera år sedan hjälpte vi till med en studie av http://Ikea.com och tittade på hur människor hittade produkter på webbplatsen. När vi kom dit hade de redan påbörjat testprocessen och använde uppgifter som "Hitta en bokhylla". Intressant nog gjorde alla deltagare exakt samma sak: de gick till sökrutan och skrev "bokhylla".
På vårt förslag gjorde teamet en subtil ändring i instruktionerna de gav sina deltagare: "Ni har 200+ böcker i er skönlitterära samling, för närvarande i lådor utspridda runt om i ert vardagsrum. Hitta ett sätt att organisera dem."
Vi såg omedelbart en förändring i hur deltagarna betedde sig med designen. De flesta klickade sig igenom de olika kategorierna och letade efter någon form av lagringslösning. Få använde Sök och skrev in fraser som "Hyllor" och "Förvaringssystem". Och ingen sökte på "bokhylla".
Det sätt på vilket du utformar uppgifter kan ha ett dramatiskt resultat på resultaten, utan att du ens inser det. I en testsituation vill deltagarna verkligen behaga dig genom att följa dina anvisningar. Om uppgifterna instruerar deltagarna att ta en viss väg är det den vägen de kommer att gå. Om det inte är vad riktiga användare gör i det verkliga sammanhanget för designens användning, kan du få förvrängda resultat.
Du kan komma runt detta misstag genom att ständigt utforska "användningssammanhanget". När du utformar uppgifter, fråga dig själv: "Vilka händelser eller förhållanden i världen skulle motivera någon att använda den här designen?" Använd svaren som den primära utformningen av de uppgifter du skapar.
Misstag #5: Att inte underlätta testet på ett effektivt sätt
Att facilitera ett användbarhetstest är en inlärd färdighet. Vi har aldrig träffat någon som varit naturligt skicklig på det. Det är inte svårt att lära sig, det krävs bara träning och övning.
En bra facilitator vet hur man lockar fram exakt rätt information från deltagaren utan att ge bort butiken. De vet hur de ska använda den mycket begränsade testtiden för att fokusera på de element som kommer att vara viktigast för laget.
Har du någonsin suttit igenom ett tråkigt prov? Det kommer inte att hända med en förstklassig facilitator. De vet hur man gör varje minut av testet intressant och spännande för de teammedlemmar som observerar.
Eftersom facilitering är lätt att lära sig är det enkelt för team att utbilda flera medlemmar till att bli bra facilitatorer. Och med mycket övning och konstruktiv kritik blir dessa facilitatorer skickliga, vilket dramatiskt förbättrar informationen som kommer ut ur varje test.
Misstag #6: Att inte planera hur du ska sprida resultaten
Ett användbarhetstest kan producera alla underverk av information, men om de personer som fattar designbesluten inte är medvetna om vad som hände har testet misslyckats. Att få ut informationen till designteamet är avgörande.
Många användbarhetsexperter försöker lösa detta problem genom att skriva testrapporter. Dessa rapporter försöker sammanfatta testningen och resultaten på ett ställe. Teorin är att om vi skriver ner det kommer alla att ha det. Tyvärr fungerar det sällan så.
De flesta rapporter blir aldrig lästa. De få som är det brukar producera fler frågor än svar. Att skriva en kvalitetsrapport som kommunicerar allt tydligt kräver fantastiska skriv- och kompositionsfärdigheter, för att inte tala om en enorm mängd tid. Tyvärr är detta saker som inte är tillgängliga för de flesta användbarhetsproffs.
Vi lärde oss för länge sedan att våra rapporter egentligen bara var till för arkivändamål, för att ge ett sätt att granska vad vi gjorde flera år senare. De var verkligen inte ett verktyg som teamet använde för att fatta beslut nu.
I stället har vi utvecklat andra tekniker för att kommunicera vad som hände under testningen, bland annat genom granskningssessioner som äger rum direkt efter varje test, genom att starta en diskussionslista via e-post för att prata om testet och olika tolkningar samt interaktiva workshops för att granska designen och vad vi lärde oss. Alla team är olika, så vi har kommit fram till att vi måste skräddarsy våra spridningsmetoder för de 2 eller 3 sätt som varje team arbetar på bäst.
Misstag #7: Att inte iterera för att testa potentiella lösningar
Användbarhetstestning är utmärkt för att identifiera problem. Ändå är den hemsk på att identifiera lösningar. Lyckligtvis har vi aldrig stött på ett designteam som inte kunde generera ett halvt dussin möjliga lösningar på något problem inom några ögonblick efter att det upptäcktes.
Problemet är att välja vilken lösning som är bäst att implementera. Du kan inte säga från det första testet, som lokaliserade ett problem, vilken lösning som kommer att fungera. Du behöver testa igen, den här gången med en fungerande implementering av lösningen. (Ofta räcker det med en pappersmodell.)
Vi ser team som hoppar över det här steget. Antingen schemalägger de inte en andra testomgång för att komma fram till lösningar eller så tar de genvägar i sin process på grund av övertro. Resultaten kan bli katastrofala - lösningen kan faktiskt vara sämre än den ursprungliga implementeringen!
Att planera en testomgång för att validera eventuella potentiella lösningar som ännu inte har upptäckts är motgiftet mot detta problem. Du måste göra detta innan du ens vet vad problemen kommer att vara. Naturligtvis, om du inte har några problem, kan du alltid avbryta testningen. (Ja, som att det någonsin kommer att hända!)
En process för att ta fram välgrundade beslut
Användbarhetstestning är en seriös investering i tid och resurser för alla team. Att ha en tydlig förståelse för vad du vill få ut av det är avgörande för dess framgång.
De mest framgångsrika teamen övervakar ständigt de beslut som kommer ut av testprocessen. De tittar på efterföljande användbarhetsproblem som uppstår och frågar: "Hur missade vår process detta? Vad ska vi byta till nästa gång?"
Endast med den ständiga processen att finslipa våra färdigheter och förbättra våra processer kan vi säkerställa att vi får det bästa värdet av denna ovärderliga teknik.
Publicerad här den 15 februari 2005.
Om författaren
Jared M. Spool är en av grundarna av Center Centre och grundare av UIE. År 2016 öppnade han, tillsammans med Dr. Leslie Jensen-Inman, Center Centre, en ny designskola i Chattanooga, TN för att skapa nästa generation av branschklara UX-designers. De skapade ett revolutionerande tillvägagångssätt för yrkesutbildning och införlivade Jareds årtionden av UX-erfarenhet med Leslies behärskning av erfarenhetsbaserade inlärningsmetoder.