[Vinklubben]

Är lite nyfiken på hur många som jobbar seriöst med användartester. Alltså inga fokusgrupper, onlineformulär eller loggfilsanalyser. Jag menar utpräglade användartester.

Så här går det till: hitta 5-6 ganska representativa (inte jätteviktigt) användare, be dem utföra de viktigaste användarmålen och granska dem. Förbättra designen > testa igen > förbättra designen > testa igen etc tills dina affärsmål och användarmål är uppnådda.

Den vanliga missuppfattningen om användartest är att det är avancerat, tar tid och kostar för mycket pengar. Detta stämmer inte. Kolla bland vänner, familj och bekanta, be dem komma över, sätt dem framför datorn, ge dem några uppgifter, be dem tänka högt och notera vad de gör. Ge dem en flaska vin som tack.

I USA spenderas 10% av webbprojektsbudgetar på användbarher och avkastningen är i snitt 80%. (Källa: http://www.nngroup.com/reports/roi/)

Själv har jag enbart positiva erfarenheter av användartester och skulle inte starta ett projekt utan dem. Den bästa designutbildningen du kan gå är att sitta bakom riktiga användare och granska dem.

[Peter]

Givetvis är det viktigt med användartester, jag håller dock inte med dig om att det inte är så viktigt med att användarna som ska testa representerar målgruppen man har för projektet.. Det viktiga är ju att se hur målgruppen reagerar, i ditt fall ska du förhoppningsvis inte vara intresserad av vad en 14-åring tycker, utan vad din riktiga målgrupp tycker. Allt handlar om målgruppen helt enkelt, i ditt fall kan man även tänka sig att personer med mycket liten datorvana kan vara en del av målgruppen, då gäller det givetvis att även leta upp dessa!

I våras var jag med och utvecklade ett bokningssystem för en stor förening i Sverige. Målgruppen för projektet var 50-80 år, ofta helt utan tidigare datorvana, mestadels svenskar, men även en del internationella gäster. När den första prototypen hade tagits fram gjordes ett kort användartest (ca 5 steg) på drygt 30 personer. Det mest intressanta var att de men mycket liten eller ingen datorvana tyckte det var lättast att använda. Då bör man givetvis tänka på att många anstränger sig lite extra för att verka duktiga, och att det därför kan vara lite missvisande. Några veckor innan systemtestningen skulle påbörjas gjordes ett komplett användartest på ca 50 personer som då fick gå igenom en komplett bokningsprocess i det fungerande systemet, vilket gav betydligt mer konkreta synpunkter. I det här läget går det väldigt snabbt att ändra kosmetiska fel, t.ex. fel text på knappar osv, som var det vanligaste rapporterade "felet" från användarna. När en användare har rapporterat synpunkter är den ofta ganska nöjd, den har funnit något som är "fel" men det är då viktigt att poängtera för denne att det felet ska åtgärdas - leta fler! Efterhand som användaren hittar saker den vill ändra på sjunker uppmärksamheten och man riskerar därför att få många synpunkter i början på testet och få eller inga i slutet.

I mitt senaste projekt hade vi inga direkta användartester utan istället ca 30 betatestare utvalda ur målgruppen som under ca 3 månader skulle använda tjänsten dagligen. Detta var ett annat sätt för oss att se vad användarna tyckte, de med stor datorvana hade mycket att kommentera, medans de med liten inte kommenterade alls, utan fick istället svara på direkta frågor om vad de tyckte skulle förbättras. Konkreta användartester där man sitter ned med användaren är med andra ord inte det ända sättet, även om det ofta är mycket bra..

//Peter

[Vinklubben]

Kul att det är en till med intresse för användbarhet!

Givetvis är bästa att få tag på så representativa användare som möjligt, ibland är det dock svårt och dyrt om du har en specifik användargrupp. Då tycker jag att det ändå värt att testa på mindre representativa användare.

Sedan är jag inte så intresserad av vad någon tycker, utan hur de beter sig. Ofta är användare mycket dåliga på att analysera sitt egna beteende. Ett typiskt exempel är fokusgrupper. Det sitter ett gäng ja-sägare i sköna fåtöljer och äter mackor och säger saker som "javisst det skulle vara bra att ha en sån grej", "Ja, det låter bra" etc. Sedan lägger man ner tid och pengar på funktionalitet som det visar sig ingen använder ändå. Något man upptäcker när man går igenom loggfilerna.

Är lite frågande kring antalet testpersoner, 30 st låter väldigt mycket. Det finns flera undersökningar som visar att runt 6 personer ger högst ROI, då upptäcker man i snitt 90 % av användbarhetsproblemenen. Visst kan man testa med mer personer men samma problem återkommer och återkommer. Bättre då att lägga in många mindre test i utvecklingsprocessen än ett stort, vilket jag upplever som ett mycket vanligt fel många gör. Det är 100 ggr dyrare att rätta till ett användbarhetsproblem du upptäcker runt produktionsdatumet än i pappersprototypstadiet.

Jag kommer ihåg ett stort företag som tidigt upptäckte att personalisering av intranätet var totalt irrelevant för majoriteten av användarna. De ville istället ha snabb tillgång till de sidor/funktioner de använde oftast. Resultat: 25% mindre utvecklingskostnad och ökad användbarhet för de vanligaste användarmålen med 67%. Detta genom en metod som kostade väldigt lite...

Dock, om det är relevans och informationsarkitektur som man testar behövs fler testpersoner, c:a 15-30.

Snabba metoder som card-sorting och pappersprototyper passar perfekt i början.