Använd användarna

den 2 juli 2008

Den största utmaningen med användartester är att hitta tid, pengar och inte minst användare att göra dem på. Helst utan att fördröja projektet. Dessutom måste experter anlitas och det tar lång tid. Eller finns det andra sätt?

De flesta som jobbar med webbplatser, antingen som konsulter eller som ansvariga på ett företag, har någon gång i nyutvecklingsprojekt eller vidareutvecklingen funderat på om de nya tankarna är rätt. Om användarna kommer att tycka att webbplatsen är bättre, om de begrepp vi nu använder är lika tydliga för dem som för oss. Samtidigt avsätts ofta för lite tid eller resurser för att testa före lansering.

Användartester dyra och tidskrävande

En bidragande orsak till att webbplatser inte testas i så hög grad, är att det upplevs som svårt och komplicerat att göra användartester. De anses dyra och tidskrävande. Inte heller är det säkert att det finns resurser att göra något åt det som konstateras som brister under testerna.

Tester görs sent

Tester görs också ofta alldeles för sent. Insatsen för att ändra blir då helt enkelt för stor. Alla som har gjort användartester vet hur svårt det är att få tag i representativa användare.

Måste användarna vara representativa?

Vad är representativa användare? Detta är inte någon exakt vetenskap, och ett enda test är faktiskt bättre än inget test. En användare, oavsett profil, är bättre än ingen användare!

Använd webbplatsens besökare

Hur svårt är det egentligen att hitta användare som är typiska för webbplatsen? En genomsnittlig företagswebbplats för ett större svenskt företag har 30–50 000 besök i månaden.  Av dessa är 20–30 000 UNIKA besökare. Det är avsevärt fler än någon någonsin har använt i användarstudier för sin webbplats! Dem kan vi använda!

Gör användartester utifrån webbplatskartan

När du ska göra användartester – utgå från webbplatskartan och testa omstruktureringar på webbplatsen innan de får genomslag i navigeringen.
Webbplatskartan är traditionellt en kopia av navigeringsstrukturen, uppvisad som ett hierarkiskt träd. Det är en relativt liten risk vi tar om vi laborerar med olika strukturer på webbplatskartan eftersom det endast är en liten del av användarna som går dit. Fördelen med detta är att vi får en begränsad grupp som vi kan studera för att se hur förändringar i strukturen påverkar var besökaren klickar.

Exempel - sammanslagning investerarrelationer och media

Innehåll som finns under rubriken Investerarrelationer finns ibland också under Media och vice versa. En lösning kan vara att slå samman dessa i en enda sektion på webbplatsen för att ta reda på:

• Förstår användarna detta? 
• Blir det för många navigeringsval?
• Rör det till det för användarna (journalister, investerare med flera)? 
• Hittar användarna till årsredovisningarna? Pressmeddelandena?

Genom att mäta användandet och klickandet via webbplatskartan kan vi bedöma hur väl vår tänkta ändring kommer att uppfattas av resten av användarna.

Exempel - olika benämningar på innehåll

Vi kan också laborera med olika benämningar för innehåll på webbplatsen. Exempelvis kan resultaträkning och balansräkning kallas ”finansiella tabeller”, ”finanser”, ”tabeller” eller ”ekonomiska tabeller”.  I statistiken kan vi snabbt utläsa vilken benämning som ger flest besök. När vi är nöjda genomför vi ändringen i den vanliga navigeringen. Och mäter även där.

Exemple - rekryteringsinnehåll

Innehåll riktat mot potentiella anställda - studenter, jobbsökande, med flera - blir allt viktigare i takt med att konkurrensen om arbetskraften ökar. Vad är det som får användarna att klicka sig vidare? Vad letar de efter?

Ska sektionen kallas CV-bank? Eller ”Career”, ”HR” eller helt enkelt ”Jobs”? Frågorna är ofta många och besluten tas mer eller mindre baserat på maggropskänsla. Eller ännu värre – sektionens namn kanske baseras på namnet på avdelningen som har hand om det på företaget.

Återigen – ändra på webbplatskartan bara. Mät. Ändra igen. Mät. Ändra igen. Mät.

Till slut vet vi, baserat på dessa användarstudier, vad som är mest tydligt för användarna. Det är i slutändan det viktigaste, eftersom strukturer och navigering handlar om att leda användarna till rätt innehåll.

Vad krävs för att göra användartester?

För att utföra användartester behövs i första hand ett CM-system som gör det rimligt enkelt att skapa och ändra i manuella versioner av webbplatskartan.

För det andra behövs ett väl fungerande statistikverktyg som gör det enkelt att följa upp hur användarna klickar på webbplatskartan mellan valda tidsperioder. Här räcker det inte med gratisverktygen som finns på marknaden utan det krävs lite mer. Inom H&H jobbar vi mest med Omnitures produkter, men bland andra WebTrends och ClickTracks  ger motsvarande möjligheter.

Varför ska jag göra användartester?

En av de viktigaste funktionerna för navigeringsstrukturen är att leda användarna till innehållet. För att kunna göra det måste begrepp och etiketter användas som användarna associerar med innehållet snarare än de begrepp du och jag skulle välja. Våra val är färgade av vår kunskap om företaget, organisationen, personerna i organisationen och det faktum att vi jobbar med detta och därmed per definition inte är typiska användare. Detta innebär att vi behöver vi testa och verifiera att vi har valt rätt. Inte sällan får man en aha-upplevelse av hur användarna gör och inte gör.

Så – glöm inte att ni har en näst intill outsinlig källa att ösa ur för era användartester!

Olika sätt att testa

Det finns många olika sätt att testa. Här listar vi några av de vanligare:

A/B-tester

A/B-tester är två olika lösningar som alterneras slumpmässigt på webbplatsen. Statistiken visar vilken av lösningarna som effektivast uppnår det önskade resultatet; exempelvis att användarna klickar vidare till en undersida.

A/B-testning är ett mycket effektivt sätt att arbeta med kontinuerlig förbättring av webbplatsen.  Vid varje ny lösning läggs inte bara den nya in, utan under en kortare period (1 vecka räcker oftast) finns båda lösningarna. Om den nya inte är bättre får man gå tillbaka till ritbordet. Om den nya är bättre , får den ta över. Det som krävs är huvudsakligen ett bra statistikprogram och lite tid.

Mer avancerade lösningar går under benämningen ”Multi-variate testing” där flera variabler involveras. Det kräver då tekniskt stöd t.ex. från Omniture eller Mazymyzer.

Grab you neighbour

Grab-your-neighbour testning som definierats av Steve Krug baseras på tanken att det är bättre att testa lite än att inte testa alls. Testning är sällan vetenskaplig och därför kan man ta sig rätt stora friheter och det är helt enkelt enklast och billigast att fråga andra i sin närvaro, dvs ”grab-your-neighbour”. Det är också detta som inspirerat till denna artikeln.

Steve Krug – Don’t make me think heter boken och man kan läsa mer på hans webbplats http://www.stevekrug.com/

User testing

User testing sker i ett labb eller hos en användare där man observerar och spelar in användarens aktiviteter. User testing kräver ofta lite större insatser och förberedelser. Här används ofta mjukvara såsom Morae (www.techsmith.com) och liknande. Enligt Jakob Nielsen (www.nngroup.com) behöver man knappt 10 användare för att komma upp på en acceptabel nivå på datat som samlas in.

Eye-tracking

Eye-tracking är avancerad analys av användarna där man följer hur ögat tittar på skärmen. Eye-Tracking är relativt kostsamt och ger bäst resultat när man redan genomfört tester och finjusterat lösningen med enklare metoder.