UX-kurs del 13, användningstester

Ett misslyckat missiltest eller en illustration av iterativt arbete!?

Om interaktionsdesign är UX-designens grundbult så är användningstester en sorts UX-designens heliga graal. Med ett användningstest kan du få alla stakeholders att kräla i stoftet inför dig.

Nåja, inte riktigt kanske. Men användningstester är jäkligt bra om du vill se hur en person interagerar med en produkt. Och det är bra med tanke på att en UX-designer rätt ofta ägnar sig åt att ta fram produkter. 

En del tycker att användningstester inte är så himla nödvändiga, för det går ju lika bra att kolla av grejerna själv. Joråsåatteeee... Faktum är att om det finns en tjänst du gillar och som är enkel att använda så är sannolikheten rätt stor att grejen har blivit användningstestad. 

En del företag har testlabb med envägsspeglar, kameror i alla upptänkliga vinklar och så vidare. Det är säkert skitbra med såna labb på många sätt. Men jag har ärligt talat rätt svårt att tänka mig en avslappnad testperson sittandes i ett sånt här labb:

"Känn dig som hemma, bry dig inte om den enorma spegeln bakom dig." Design (kanske) by Josef Fritzl.

Dock: jag får väl erkänna att jag aldrig har jobbat med ett sånt här labb, så bry er inte allt för mycket om det jag skrev ovan.

I alla fall.

När ska man göra användningstester? Och blir det inte väldigt dyrt? är frågor man kan ställa sig. Ok, jag låtsas att någon ställde just de frågorna. 

Svaren är att du ska göra användningstester oftare än du tror och det är inte dyrt. Men för att det här inlägget inte ska vara superkort så tar jag och utvecklar det hela lite.

Är det inte jäkligt dyrt?

Nej. Det är inte jäkligt dyrt. Att bygga en produkt och plöja ner mängder av timmar och energi och pepp, bara för att se den floppa pga obegriplighet och sugigt användargränssnitt är dyrt. Det är däremot väldigt billigt att ett par gånger i månaden stämma av om det man tror är en gudomligt smart idé är en gudomligt smart idé, eller om man drömt ihop något fullständigt vansinnigt pga group think och andra lustiga företeelser. Du gör tester för att det ska bli bra och då blir det billigare i slutändan. 

Kostnadsaspekten hänger ibland ihop med en sorts rädsla att kraschtesta sin design. För tänk om det inte var något bra, hur blir det då med min streetcred på företaget? Den här rädslan maskeras ibland med en kostnadsaspekt: "Närå, vi kan testa internt, vi vet vad användarna vill ha. dessutom blir det jäääkligt dyrt och vi ligger redan efter i tidplanen. Kolla bara mitt GANTT-schema här. Nästa milestone är redan på måndag. Mmm-kaaayyy?"

Den här oviljan att utsätta sina idéer för verkligheten är märkligt nog rätt vanlig hos folk. Kanske särskilt hos de som har mycket att förlora på att idén är dålig. Men det är väl rimligtvis bättre att testa om idén är bra INNAN den stora releasedagen? Kan man tycka.

Hur gör man användningstester?

Att göra ett användningstest är ingen särskilt avancerad apparat. I alla fall om man inte vill göra det till en sådan. Men då blir det dyrt. Och vi vill inte att det ska vara dyrt. Det finns en fin bok som Steve Krug skrev en gång i tiden. Den heter Rocket surgery made easy. Förutom att bokens titel är fullkomligt brilliant (jag gubb-skrockar nöjt varje gång jag tänker på den) så är innehållet väldigt bra. Den behandlar hur man gör användningstester billigt och enkelt och utan utrustning som påminner om CIA:s Polygraph-test. Men eftersom jag av copyrightskäl förmodligen inte får citera hela boken här så gör jag ett eget försök av mina egna erfarenheter. Here we go:

• Ring några personer. Helst såna som tillhör målgruppen, men i värsta fall går det bra med vem som helst. I alla fall om det ni designar inte är något superspecifikt. Men ponera att du är med och tar fram en tjänst som ska hjälpa folk att matcha ihop folk som har beggade kläder med folk som vill ha beggade kläder, då går nog vem som helst bra att använda som testperson. Om du designar ett nytt VR-gränssnitt för stridspiloter kanske du inte kan höra av dig till kompisarna i Mammagruppen, däremot. Förutsatt att ingen av dem är stridspilot förstås. Be dem komma och hälsa på på kontoret med en timmas mellanrum ungefär. Eller för added mysighet: besök dem hemma eller på deras jobb om det är ok för dem.

• Förbered ett test. Ofta brukar jag försöka testa av grejer som jag har en känsla av är lite skeva och såna grejer som är centrala för att hela konceptet ska hålla ihop. Testet brukar innefatta dels lite "hur känns det här då" -frågor och "vad tror du händer om du gör så där"- frågor, men framför allt så brukar jag sätta ihop några scenarion. Till exempel: "Du är trött på att garderoben är full av kläder du inte använder, men orkar inte gå ner till stadsmissionen. Istället har du beslutat att ge bort dem. Här har du en app på din telefon, kör hårt!" Eller "Det plingar till i telefonen, ett sms säger att du har en intressent för en av dina klädhögar. Vad gör du nu?" Sen får testpersonen helt enkelt berätta vad den gör och visa på de skisser/den prototyp/ det färdiga systemet eller vad det nu kan vara.

• När några personer har gjort samma test (en och en givetvis), så sammanställer du dina observationer. Förhoppningsvis så upptäcker du ett mönster i deras beteende och vips så har du förbättringsförslag. Bra va!?

• Justera det du upptäckte och börja om från början. Till slut har du the design to rule them all.

"Men Eric", frågar nu den präktiga eleven längst fram i klassrummet, "hur vet jag att jag har hittat alla problem med designen?" Jag är glad att just du ställer just den här frågan. Svaret är att det vet du inte. Jobbigt va? Men du känner garanterat till fler problem med designen än du gjorde innan. Eller hur? 

Om man inte upptäcker några risker med sitt designkoncept så har man förmodligen gjort minst ett av två (eller flera fel):

Man var för feg när man tog fram sitt designkoncept och/eller testet är felaktigt genomfört på något vis. Man kanske väldigt väldigt gärna vill att testet ska "gå bra" och hjälper testpersonerna lite för mycket om de kör fast, till exempel. Ett test utan jobbiga resultat är en varningsklocka. Så sluta vara feg som ux:are och sluta upp med att fuska med testerna. Det är som att fuska i patiens. Meningslöst.

När gör man användningstester?

Så fort och så ofta man orkar. En del verkar ha fått för sig att ett användningstest endast kan göras på en färdig eller nästan färdig produkt, för annars går det ju inte att klicka på knapparna. Ja, det låter ju väldigt rimligt. Jag är säker på att det är så man gör när man ska testa om en ny typ av bromsar funkar på en bil: Bygg klart hela bromsssystemet och sen ut på vägarna. Full fart, ba! Annars vet man ju inte om det funkar for realz.

Nej. Givetvis testar man även på tidig konceptnivå, fast då har testet kanske ett annat tema. Istället för att kolla om knapparna sitter rätt så kanske man ser ifall den konceptuella idén överhuvudtaget är begriplig eller om man varit för smart när man tog fram det nya konceptet. Men man testar också färdiga, halvfärdiga och trekvartsfärdiga produkter.

Hur ska man dema testresultatet?

För det första är det absolut bästa om chefens chef sitter med på testet, förutsatt att hen kan hålla flabben under testets gång. Annars blir det rött kort. Även andra personer ur teamet är hemskt gärna välkomna. Men någon måtta får det vara: man kan ju inte sitta där 12 personer och glo på när någon stackare försöker få ordning på det designförslag som testas. Stämningen kan nog bli lite lätt awkward då.

En annan bra grej kan vara att spela in det som händer på skärmen samtidigt som man spelar in det som testpersonen säger. Sen kan man köra en demo och visa alla hur muspekaren åker omkring samtidigt som testpersonen desperat pratar på om hur hen tänker. Det är sjukt effektivt. Det är också något som öker på komplexiteten ytterligare: en grej som diskuteras i UX-kretsar är vilka screenreaders som är bra och det är rimligtvis ett tecken på att den här approachen är lite omständlig. Men om du får den att funka så är det jäkligt mäktigt och funkar som ett sjukt starkt argument: "jaha, men du såg ju själv, fyra av fem hittade inte de FAQ-frågor de behövde. Det kanske kan tyda på något, eller vad tror du om det?"

Det vanligaste är nog annars att man helt enkelt, kanske med lite screenshots, berättar hur det gick. Det är minst effektfullt, men enklast.


Sammanfattningsvis: Användningstester är ett billigt och bra sätt att ta reda på om det man har designat är bra eller inte. Det funkar lika bra på koncept som på färdiga produkter.