Nästa steg i det som börjar bli en användbarhetstestserie, är att ta fram uppgifter till användaren som ska delta i testet. Om du undrar vad för ”användbarhetstestserie” jag pratar om så se mitt tidigare blogginlägg ”Användbarhetstest – när användaren blir testare”. I den texten, precis som den här, så utgår jag från mina egna erfarenheter under ett användbarhetstest av ett pekskärmsgränssnitt till ett kassasystem.

När du läst den här blogg posten vill jag även rekommendera dig att läsa mer om test och kvalitetssäkring som du hittar i vår kunskapsbank genom att klicka här.

Först – en varning!

Eller egentligen flera.

Försök inte testa allt. Precis som med all annan typ av test så måste man prioritera och fokusera på det viktigaste. Vet man inte vad som är viktigast, ta reda på det!

Testar gör man för att hitta fel och göra något åt dem. Om det inte finns utrymme för att införa förändringar i produkten baserat på resultatet från användbarhetstestet, strunta hellre i det helt!

Testsessionerna får inte bli för långa, tänk därför på att inte ha med alltför många uppgifter. Under pekskärmstestet satte vi gränsen vid en timme, men testtiden är naturligtvis beroende på vad som testas och vilka användarna är. Kontrollera i en testpilot ungefär hur lång tid det tar att utföra uppgifterna.

Det som görs ofta ska vara enkelt

För att ta fram uppgifter, utgå från produkten huvudsyfte och beskriv användningen av produkten för att uppnå dessa mål. Fokusera på de funktioner som används oftast och på de som är viktigast. I en kassa så är det viktigaste att kunna slå in varor, kunna ta betalt, få rätt subtotal och ge rätt växel. Utöver dessa uppgifter så finns det en mängd andra funktioner i kassan som kanske inte är lika oumbärliga för syftet med produkten men som ändå används dagligen och därför också bör övervägas att tas med i testet.

Under pekskärmstestet föreföll det självklart att ta med primära uppgifter som att sälja varor i kassan och ta betalt. Dessutom tog vi med uppgifter för att rätta bort en vara från kvittot, ändra antal registrerade varor och betala med lite olika betalmedel. Kort sagt alla uppgifter som utförs flera gånger om dagen av en kassör. I ett kassasystem är det tämligen lätt att skilja ut vilka funktioner som är av störst vikt hos produkten, men det finns andra system vars basfunktionalitet inte är lika uppenbara.

Rådet är att först och främst formulera uppgifter som ger svar på frågor kring produktens vanligaste och/eller viktigaste användning.

Har någon varit extra kreativ?

swipeNya produkter och system bäddar för ny funktionalitet eller ny design som antas tillföra användandet av produkten ”det lilla extra”. Det kan vara en god idé att testa om de nya kreativa lösningarna var så smarta som designteamet hoppades på.

Under utformningen av gränssnittet till pekskärmskassan så hade utvecklaren, som även agerat designer, valt att användaren skulle kunna byta mellan menyerna på samma sätt som när man använder en Smartphone, det vill säga genom att dra med fingret över skärmen (på svengelska brukar man prata om att ”swipa”). Tanken var god, utvecklaren hade god skäl att anta att de allra flesta har en Smartphone och vet hur man interagerar med en sådan, därför borde det vara behändigt om gränssnittet till kassan fungerade likadant. Dessutom skadade det inte om pekskärmskassan associerades med något så högteknologiskt och hippt som en iPhone. Tyvärr så kopplade inte användarna ihop pekskärmskassans gränssnitt med Smartphonens. INGEN av testpersonerna luskade ut hur de skulle navigera i menyerna. Även när användaren fått tricket avslöjat så hade de flesta fortfarande svårt att byta meny. Anledningen till detta var att användaren inte kunde dra fingret över skärmen från kanten utan var tvungen att dra över det område där menyerna låg, det vill säga en begränsad del av skärmen. Ett annat problem var att vissa av användarna råkade trycka på knapparna i menyerna när de ville byta meny, medan andra istället misslyckades eftersom de helt försökte undvika att dra fingret över knapparna.

Med hjälp av användbarhetstestet kunde man upptäcka den här problematiken som antagligen annars upptäckts först när produkten var i drift. Lärdomen är att det är svårt och ibland omöjligt att sätta sig in i hur den faktiska användaren tänker.

Kombinera uppgifter med intervju

Att ge användarna uppgifter och observera eller till och med filma utförandet kan ge värdefull information och aha-upplevelser till utvecklingsteamet. Det väcker dock oftast också en del frågor. Den vanligaste är: ”varför i hela friden försöker användaren göra på detta viset?”.

Förhoppningen är att användbarhetstestet ska visa vilka brister och problem som finns i produktens gränssnitt, men om man dessutom förstår vad användaren tänker och varför problemet uppstår då har man ett bra underlag för att hitta en alternativ och bättre design. Det finns två råd att ge för att åstadkomma detta i ett användbarhetstest:

1. Think aloud – be användaren ”tänka högt” under testets genomförande. På så sätt så får man lättare att förstå vad användaren försöker göra och hur denne uppfattar produkten. Vissa användaren tycker att det är lite obekvämt att prata högt för sig själv, så man kan behöva påminna testpersonen att tänka högt under testets utförande.

2. Intervju – Intervjua testpersonen om upplevelsen av produkten och uppgifterna, vad är användarens egen analys av vad som gick snett och varför? Hur skulle användaren hellre vilja att gränssnittet såg ut och betedde sig? Intervjun kan ske efter att alla testuppgifterna är utförda eller så kan man intervjua personen efter respektive uppgift. Se bara till att vara konsekvent och att göra på samma sätt i alla testsessioner.

ClarkEtt användbarhetstest kräver en del förberedelser och att man följer sin planering i detalj, annars blir det lätt knas på vägen som skadar tillförlitligheten i testet. När testernas genomförande är planerade, användare rekryterade och uppgifter framtagna, samt testet är testat i en testpilot, ja då är det bara att köra!

Testpilot – En pilot är en första körning av testet för att verifiera att själva testet i sig är utformat på bästa sätt. En pilot ger en bra indikation på hur lång tid uppgifterna tar att utföra, hur mycket information användaren behöver och om uppgifterna är formulerade på ett tydligt sätt.

Ulrika Löthgren, Senior konsult, Systemstrategerna. Utbildad inom interaktionsteknik och design, har jobbat med test och projektledning som konsult och i produktbolag sedan 2006. Brinner särskilt för användbarhet och agila metoder.