Syftet med att utvärdera en produkts användbarhet är att göra produkten bättre. Detta kan tyckas självklart, men det är alltför ofta som resultatet av en utvärdering presenteras på ett sätt som i princip gör det omöjligt att veta vad man skall göra åt bristerna, och var man skall börja.

Det som är viktigt att tänka på när man genomför utvärderingar är att de alltid bör:

1. utgå från syftet med produkten
2. baseras på de vanligaste och/eller viktigaste uppgifterna som användaren förväntas göra
3. resultera i en åtgärdslista som prioriterats utifrån verksamhetseffekt
4. inkludera förslag på omdesign som skulle åtgärda problemet

Utvärderingar kan göras när som helst. Mitt under projektet, om man t.ex. känner sig osäker på om den tänkta utformningen är så bra som den måste vara, eller när produkten är i drift, för att få underlag för ytterligare förbättringar.

Det finns i huvudsak två olika sätt att utvärdera ett systems användbarhet:

• Expertgranskning. Systemet granskas av en användbarhetsexpert, som går igenom systemet utifrån sin kunskap om ”best practice” och riktlinjer för just denna typ av system, och hur vi fungerar som människor. I denna typ av granskningar är det ofta bra att luta sig mot någon form av heuristiska regler.
• Användbarhetstest. Systemet testas med riktiga användare som utför de uppgifter som är viktigast för att systemet skall generera de önskade verksamhetseffekterna. Testet genomförs ofta med en till två användare åt gången, och bör genomföras i den miljö som systemet sedan är tänkt att användas i. Användbarhetstester kan också genomföras på avstånd (s.k. remote usability testing), och om man vill ha extra stöd i analysen kan man använda teknik för ögonrörelsespårning för att se exakt var på skärmen testpersonen tittar.

Syftet med en expertgranskning är att finna avgörande brister, till en mycket låg kostnad. En granskning av detta slag kan göras med olika ambitionsnivå och tar vanligtvis inte mer än 1-5 dagar.

Resultatet av granskningen blir en förteckning över brister, och helst också förslag på åtgärder.

Särskilt uppmärksammas bristande konsekvens, otydlig eller förvirrande interaktion, hur väl produkten är utformad för att stödja hur vi som människor läser och tolkar information och hur väl förslaget följer gängse standarder.

Expertgranskningar kan genomföras så snart som ett helt eller delvis klart användargränssnitt finns som pappersprototyp eller i körbar form.

I lågbudgetprojekt kan det vara den enda användbarhetsaktivitet som görs, eller om projektet Expertutvärdering kan vara en enstaka aktivitet som ”läggs till” till i ett projekt som saknar andra användbarhetsaktiviteter. I ett projekt där användbarhet är en integrerad del av projektet görs expertutvärdering i god tid innan ett användbarhetstest. Expertutvärdering kan också vara ett bra sätt för beställare av IT-tjänster att få förståelse för vad ”det här med användbarhet” är, eftersom beställaren på kort tid får konkreta tips på åtgärder som förbättrar produkten. Därför är expertutvärdering också en bra tjänst för att ”sälja in” användbarhet.

Expertutvärdering utförs av en interaktionsdesigner. Den som genomför expertutvärderingen ska inte själv ha ansvarat för designen av produkten eller prototypen.

Expertutvärdering kan genomföras på kort tid, från några timmar till upp till två veckor. Hur mycket tid som läggs beror dels på hur välunderbyggt och fylligt material man vill ha ut från utvärderingen, och dels på produktens komplexitet.

De aktiviteter som ska genomföras följer ett och samma mönster:

1. Definiera produktens syfte och bestäm omfattning. En expertutvärdering förutsätter alltid att den som ska utvärdera produkten får information om målgrupperna, användningssituationer, uppgifter och inte minst produktens syfte. Detta sker oftast i en diskussion med beställaren, där också omfattning och inriktning för utvärderingen definieras. Ta reda på vilka delar som ska utvärderas, gärna formulerat som de uppgifter användarna skall lösa med hjälp av produkten. Bestäm om rapporten ska innehålla designförslag, eller om det räcker att problemen beskrivs. Boka tid för redovisning och ta reda på vilka personer som kommer att delta på redovisningen. Räkna med ca 2–4 timmar för en sådan diskussion.
2. Genomgång av produktens innehåll och utformning. Det är bra om någon som ansvarar för användargränssnittet kan demonstrera produkten med fokus på de delar som särskilt betonats av beställaren. Du ska inte själv använda produkten i detta läge av två skäl. (1) Det är mycket svårt både ha fokus på att använda en ny och för dig okänd produkt (en tankeprocess som kräver full uppmärksamhet på detaljer), och samtidigt betrakta utformningen som expert (en tankeprocess som kräver överblick). (2) Genom att observera hur den som har utformat produkten faktiskt gör när hon använder produkten så kan du upptäcka handgrepp som är dolda eller otydliga för en utomstående. Om du själv skulle använt produkten skulle du kanske aldrig upptäckt dessa funktioner. Ställ frågor om gjorda designval och bakgrunden till dem. Räkna med ca 2–4 timmar för en sådan genomgång.
3. Utvärdera produkten. Du gör utvärderingen genom att ställa dig frågor som motsvarar de frågor du tror att användarna har. Utför de vanligast förekommande uppgifterna för den viktigaste målgruppen först. Skriv rapporten parallellt med utvärderingen och se till att det framgår i rapporten hur allvarligt problemet är, d.v.s. hur mycket du tror att det påverkar det mål som de som ligger bakom systemet har med det. Kom också ihåg att beskriva vad som är bra utformat, annars blir det en onödigt deprimerande läsning för de som varit med om att ta fram det som finns idag. Dessutom minskar man då risken att det som är riktigt bra försvinner i samband med någon annan ändring.
4. Rapportera. Planera presentationen så att de viktigaste problemen som måste åtgärdas presenteras först. Om utvärderingen också ska innehålla designförslag, se till att du har förberett flera olika designförslag och presentera fördelar och nackdelar med varje. Räkna med minst 4 timmars förberedelsetid för att ta fram presentationen.

Utöver förståelse för målgrupper, användningssituationer, uppgifter och produktens syfte behöver du kunskaper om hur det mänskliga systemet fungerar och hur interaktiva gränssnitt kan anpassas utifrån denna kunskap.

I kapitlet Vidare läsning finns många bra rekommendationer när det gäller t.ex. böcker och webbplatser som kan hjälpa dig att komma vidare och bli bra på att göra användbarhetsgranskningar. Kunskap om plattformsstandarder och om allmänt vedertagna riktlinjer för att lösa vanliga interaktionsfrågeställningar behövs också.

När du gör expertutvärderingar kan du dessutom använda olika tumregler för att kontrollera att du får med ”allt”. Jacob Nielsens ”10 Usability Heuristics” är en klassiker som fortfarande håller:

1. Enkel och naturlig dialog. Dialoger bör inte innehålla irrelevant eller sällan använd information då denna tävlar med den relevanta informationen och minskar dess relativa synlighet. All information bör komma i en naturlig och logisk ordning.
2. Använd ett naturligt språk. All text bör utformas i ord, fraser och begrepp som är bekanta för användaren istället för i systemorienterade termer.
3. Minimera användarens minnesbelastning. Gör valbara objekt och funktioner synliga. Användaren ska inte behöva komma ihåg information från en del av produkten till en annan. Instruktioner för användning av systemet ska vara synlig eller lätt att få fram.
4. Enhetlighet. Användare ska inte behöva fundera över om olika ord, situationer eller handlingar i systemet betyder samma sak. Följ plattformsspecifika riktlinjer.
5. Förse användaren med återkoppling. Systemet ska inom rimlig tid informera användare om vad som sker i systemet.
6. Förse användaren med klart markerade funktioner för att avbryta dialogen. Användare väljer ofta systemfunktioner av misstag och behöver en klart markerad ”Nödutgång” för att hitta tillbaka. Gör det möjligt att ångra och repetera.
7. Effektiv användning. Kortkommandon snabbar ofta upp interaktionen för experten. På så sätt kan systemet tillgodose både oerfarna och erfarna användare.
8. Bra felmeddelanden. Bra felmeddelanden uttrycks i ett enkelt språk, som klart och tydligt indikerar vad som är fel och föreslår en lösning på problemet.
9. Förhindra fel. Bättre än ett bra felmeddelande är att utforma produkten så att problemet inte uppstår.
10. Hjälp och dokumentation. All hjälp och dokumentation ska vara lätt att söka i, fokuserad på användarens uppgift, lista konkreta arbetssteg och inte vara för omfattande.

Ett användbarhetstest är en kostnadseffektiv teknik att fånga hur väl en produkt fungerar i en konkret användningssituation¹. Genom att låta användare utföra realistiska uppgifter identifieras eventuella problem som kommer att uppstå när produkten ska användas. Framför allt fångas möjliga orsaker till problemen, vilket gör att man får ett bättre underlag för att åtgärda dem, och därmed bygga en bättre produkt.

Användbarhetstestet ska utföras i så realistisk miljö som möjligt. Helst ska alltså testet utföras i användarens vardag, men ofta finns tekniska eller andra hinder för detta.

Det är inte alltid som man formulerar åtgärdsförslag när man genomför ett användbarhetstest, men man är alltid tydlig med att formulera vilka problem som uppstod och vilka orsakerna till dessa sannolikt är.

Användbarhetstest i den tappning som beskrivs här bygger på en teknik utvecklad av Wright och Monk 1991². Grundprincipen är att det finns en användare och en handledare och att användaren uppmanas att ”tänka högt” medan handledaren ställer frågor som gör att det blir klart vilken bild av produkten som användaren har vid varje tillfälle.

Det finns några olika sätt att genomföra användbarhetstester:

Strukturerat användbarhetstest. Ett strukturerat användbarhetstest innebär att en användare får ett antal realistiska uppgifter som ska lösas. Användaren ska lösa uppgifterna och ”tänka högt”, d.v.s. förklara sina tankar under tiden. Användbarhetstestet upprepas med samma uppgifter vid minst 5 sessioner, med en användare i varje. Uppgifterna formuleras endera utifrån uppställda användbarhetsmål eller utifrån frågeställningar runt viktiga funktioner eller egenskaper hos produkten. I ett strukturerat användbarhetstest finns tre till fyra olika roller. Användaren - den som har kunskap om tillämpningsområdet. Testledaren – ansvarar för att användaren känner sig tillfreds och att ställa frågor som klargör användarens bild av produkten. Observatören – har till uppgift att notera vad som händer. Vittne – en person som har intresse av utvärderingen, ofta beställaren eller annan verksamhetsansvarig. Ibland är vittnet också observatör. Rollen kan uteslutas.

Partest. Ett partest bygger på att användarna jobbar i par och diskuterar sinsemellan för att lösa ett antal uppgifter. Handledarens roll är att följa diskussionen och ibland leda den rätt. Partest passar mycket bra om man behöver mer bakgrundskunskap om hur användarna betraktar det område som produkten ska stödja.

Walk-up-and-use. Publika produkter ska ofta fungera trots att användaren har mycket liten förkunskap om produkten. I ett sådant test definierar användaren uppgiften och genomför dem. Handledarens roll är att uppmuntra användaren att ”tänka högt” och att ställa frågor. Problemet med denna typ av utvärdering är att varje användare kommer att utföra olika uppgifter, det blir alltså svårare att dra generella slutsatser.

Ett användbarhetstest kan genomföras i olika skeden. I tidiga faser kan tester ske på pappersprototyper, och senare på körbara prototyper eller färdiga produkter. Om man vill utvärdera en användares upplevelse av produkten är det självklart viktigt att så många detaljer som möjligt är klara. Om man istället vill utvärdera vissa koncept eller viss funktionalitet räcker det att just dessa delar är klara och då behöver de inte heller vara snyggt utformade. En prototyp på papper eller i körbar form är ofta tillräckligt funktionella för att utvärdera grundkoncept, förutsatt att inte grundkonceptet kräver realtidsuppdateringar, stora datamängder, eller annat som ställer krav på ett körbart lösningsförslag. Om produkten saknar funktioner och detaljer som är väsentliga är det handledarens uppgift att täcka upp där produkten inte fungerar genom att berätta hur det kommer att fungera på ett sådant sätt att uppgiften kan slutföras.

Användbarhetstest kan vara en enstaka aktivitet som ”läggs till” ett projekt som saknar andra användbarhetsaktiviteter. I ett projekt där användbarhet är en integrerad del av projektet är det bra att göra minst tre användbarhetstest; det första för att utvärdera vissa bärande principer, det andra för att utvärdera viktiga detaljer och det tredje för att utvärdera produkten som helhet. I praktiken är dock ett användbarhetstest bättre än inget!

I ett användbarhetstest finner man alltid problem som behöver åtgärdas. Därför är det mycket viktigt att du ställer frågan om projektet har tid och råd att åtgärda de problem som man kommer att finna. Om svaret är nej, då bör man inte heller lägga tid och pengar på ett användbarhetstest.

Hur genomför man då ett strukturerat användbarhetstest? Till att börja med så är det inte lämpligt att vara testledare om du varit inblandad i designarbetet för produkten som skall testas. Då finns nämligen en överhängande risk att du omedvetet kommer att leda användaren med dina frågor, och att du gör felaktiga antaganden om hur användaren uppfattar produkten. Om du varit involverad som designer kan du däremot med fördel delta som observatör.

1. Bestäm vad som ska utvärderas och hur

Ta reda på vad det är som är viktigast att utvärdera och ställ det mot hur mycket funktionalitet som finns färdig eller kan finnas klar då testet ska genomföras. Ett exempel: ett baskrav på en produkt där jordbrukare ska söka EU-stöd och uppdatera kartor är att det är enkelt att rita på den digitala kartan. Om inte karthanteringen är i körbart skick är det förmodligen inte meningsfullt att testa.

Bestäm också på vilket sätt anteckningar skrivs, och vad de ska innehålla. Ska observatören notera antalet misslyckade försök, hur lång tid det tar etc? Ska notationen följa en mall, eller är det fritext etc. Besluta vilka av de definierade målgrupperna som bör delta i utvärderingen. Om det är första tillfället som produkten utvärderas är det sällan nödvändigt att ta med representanter för alla målgrupper.

Ta reda på hur resultatet kommer att användas och i vilken form som det skall presenteras. Ibland är det lämpligt att videofilma, särskilt om resultatet ska presenteras för många människor och vid olika tillfällen.

2. Ta fram realistiska uppgifter

Formulera uppgifter som kan ge svar på de frågor du definierat. Uppgifterna ska inte vara för många och ska sammanlagt inte ta mer än cirka 2 timmar att utföra. Formulera uppgifter som hänger ihop på ett naturligt sätt. Det kan exempelvis betyda att man i en senare uppgift gör tillägg eller ändrar något man gjort tidigare.

Den första uppgiften bör vara så enkel att användaren inte kan ”misslyckas”. Målet med första uppgiften är att det ska vara enkelt för användaren att komma igång. Den sista uppgiften ska också vara relativt enkel, för att användaren ska avsluta testet med en känsla av tillfredsställelse. Däremot bör uppgifterna i mitten definitivt ge svar på frågeställningarna som finns.

Uppgifterna måste självfallet spegla sådant som användaren normalt gör i sitt dagliga liv, de ska vara realistiska. Skriv korta uppgifter, en på varje sida. Exempelvis ”Finns det någon resa till Kanarieöarna vecka 12?”.

Testa uppgifterna innan användbarhetstestet! Lämna uppgifterna till utvecklarna för att kontrollera om du gjort några tankemissar: funktioner som saknas eller liknande. Provkör själv så att du ser hur lång tid uppgifterna kan ta att genomföra. Låt någon som känner till området läsa uppgifterna och berätta vad hon tror att du vill att hon ska göra. Om det finns en referensgrupp så kan du också testköra uppgifterna tillsammans med någon eller några från referensgruppen.

Beställaren och utvecklingsteamet har ofta frågeställningar som inte direkt går att formulera som uppgifter, exempelvis ”skulle du föredra att använda produkten framför en annan produkt?”. Denna typ av frågor ska du också formulera för att kunna ställa dem till användaren i en diskussion efter testet. Ibland kan det finnas många frågor av denna typ och då kan du fundera på om du ska använda en enkät för detta. Huvudsaken är att frågorna ställs direkt i anslutning till testet.

3. Säkra data och funktioner

Säkerställ att realistiska data finns då testet ska genomföras. Kontrollera att all funktionalitet som skall testas kommer att finnas på plats. Var beredd på att ändra lite i testet om viss väsentlig funktionalitet saknas.

4. Lär dig produkten

Du bör själv kunna produktens alla funktioner, framför allt de som ska utvärderas, men även andra. Som handledare har du ansvar för att hjälpa användaren att hamna rätt i de fall hon leds fel och måste därför kunna mer än vad som ingår i testet. Du ska också, efter sessionen gå igenom testet med användaren och då självfallet kunna förklara och ställa frågor runt delar som inte ingår i testet och kanske ännu inte finns byggda.

5. Praktiska förberedelser

Om inte testet utförs i användarens vardagsmiljö så måste ett särskilt rum iordningställas. Kolla möblering och rummets känsla. Ta dit blommor, avställningsbord och mattor om det behövs. Om testet ska filmas så ska du skaffa och testa utrustningen. Se till att det finns något att dricka och lite frukt.

Kontrollera med beställaren på vilket sätt användarna ska kompenseras för den tid de lägger ned. I vissa fall behövs en ekonomisk ersättning och det ska då framgå av inbjudan. I andra fall kan ersättningen vara en sak, exempelvis en biobiljett eller en ask choklad.

Planera tillräcklig tid per session och gör upp ett schema för varje session med tider och vilka som deltar i vilken roll.

Gå igenom hur testet ska genomföras med observatörer och vittnet;

• Gå igenom schemat.
• Gå igenom vad testet syftar till och vad du vill att de ska vara mest uppmärksamma på.
• Gå igenom gången för en normal session – att du håller i det hela och att den innehåller presentation, utvärdering och summering.
• Bestäm när och hur ni tillsammans ska gå igenom varje session. Bäst är att summera fakta och intryck direkt efter sessionen.
• Gå igenom hur anteckningarna ska skrivas. Några olika sätt att göra det på finns, men en enkel lågbudgetversion är att notera användarens kommentarer och handlingar i sekvens.
• Förklara villkoren, exempelvis att de inte kan ha mobiltelefon på och att de inte kan lämna rummet eller komma in mitt i en session. En checklista som du kan lämna till observatörerna hittar du i bland wikins exempel och mallar. Om ett vittne ska delta är det extra viktigt att betona att hon inte kan samtala med användaren eller svara på frågor under sessionen. Däremot har vittnet en viktig roll före och efter sessionen.

6. Bjud in deltagare

En inbjudan ska förklara för användaren varför hon skulle delta i testet, hur det går till och vad som förväntas av användaren.

Exempel på inbjudan hittar du i bland exempel och mallar.

7. En session

Börja alltid med att presentera dig själv och hur testet kommer att gå till, meningar som dessa kan vara användbara:

• Välkommen, jättebra att du kunde delta!
• Vi ska idag göra ett test av Produkt X och vi behöver din hjälp för att få veta hur bra produkten är just nu.
• Utvärderingen går till så att du kommer att få 10 uppgifter som du ska lösa med hjälp av Produkt X. Det är viktigt att du ”tänker högt” d.v.s. hela tiden berättar allt som du tänker och vilka associationer som du gör.
• Jag är testledare och kommer att hjälpa dig närhelst ett problem uppstår. Jag kommer att se till att vi klarar oss igenom testet på utsatt tid och utan större problem.
• Jag kommer inte att berätta hur du ska lösa uppgiften, d.v.s. vad en knapp betyder, eller vad som kommer att hända om du klickar på en specifik länk. Skälet är helt enkelt att vi vill veta om produkten fungerar så som vi tänkt. Om jag talar om hur det är tänkt att fungera så missar vi alltså hela syftet med testet.
• Det är alltså produkten vi testar och inte dig. :-)

När genomgången är klar bjuder du användaren att sitta ned. Placeringen bör vara sådan att du ser allt som användaren gör utan att skymma för observatör och ett eventuellt ”vittne”.

När du ska introducera användaren bör du se till att det är helt klart hur hon ska jobba. Några användbara meningar är:

• Arbeta med en uppgift i taget.
• Läs uppgiften högt. Försök lösa uppgiften med hjälp av systemet.
• Tänk högt under arbetet och kommentera allt som händer. Prata på hela tiden, ställ frågor, berätta dina intryck!
• Om du inte förstår, fråga – jag kommer att hjälpa dig!

Under sessionen har du till uppgift att få användaren att känna sig tillfreds. För att lyckas måste du använda dina kunskaper om det sociala spelet och all din charm! Några bra förhållningsregler är:

• Om användaren inte kommer igång med att lösa arbetsuppgiften, säg t.ex.:


– Ok, hur tror du vi ska göra för att lösa det här?

• Svara inte direkt på frågor och funderingar. Försök diskutera fram en lösning med användaren. Det hans/hennes handlingar, reaktioner och uttalade tankar och känslor som är vårt material. Om du hjälper till, får vi aldrig veta vad som leder användaren fel! Kommentera istället för att svara ja eller nej:


– Pröva och se vad som händer.
 – Testa.

• Ställ kontrollfrågor löpande för att fånga användarens tolkning av produkten exempelvis:
– Var har vi hamnat nu?
– Vad är detta för funktion?


– Varför är listan i den här ordningen?

• Om användaren fortfarande har problem kan du ställa stödjande frågor och leda användaren rätt genom att säga exempelvis;
– Det verkar inte finnas här.


– Har du provat alla ställen?

• Om användaren fastnar fullständigt får du naturligtvis ge hjälp så att utvärderingen kommer igång igen.

• Om användaren tystnar, är det din uppgift att få igång pratet igen! Kommentarer för att påminna utvärderaren att tänka högt kan t.ex. vara:


– Vad tänker du på …
 – Vad söker du efter …

• Som Handledare ansvarar du för att den bild som du har av användarens förståelse av produkten är korrekt. Du måste därför, för att kontrollera din egen förståelse ställa kontrollfrågor:


– Varför gjorde systemet så … 
– Vad trodde du skulle hända …
 – Vad tror du händer om …
 – Vad har systemet gjort nu …

• Fråga om användaren anser att hon slutfört uppgiften. Ge alltid positiv bekräftelse, även om användaren hade problem att genomföra uppgiften. Handledarens uppgift är att få användaren att känna sig tillfreds och i det ingår att ta bort osäkerhetskänslan. Det är systemet som utvärderas, inte användarens prestation!

8. Efter varje session

Efter varje session, när användaren gått, ska du som Handledare leda en genomgång av resultatet. Fråga först vilka händelser som deltagarna ansåg mest signifikanta och diskutera igenom dem. Fråga sedan om sådant som du själv inte är säker på att du uppfattade under sessionen. Skriv stödord under genomgången.

Kontrollera sedan att du kan läsa de andras anteckningar, skumläs och se om du finner något oklart.

9. Skriv rapport/presentation

Att skriva rapporter från denna typ av tester kan ta oändligt med tid. Särskilt om man inte har någon bra strategi för sitt skrivande.

Ett vanligt misstag är att man börjar från början i materialet och tar med ALLT som verkar vara av intresse. Detta är problematiskt eftersom det då är omöjligt att avgöra hur lång tid det kommer att ta att skriva hela rapporten, vilket innebär en överhängande risk att du hamnar i tidsnöd i slutet. Detta medför flera problem:

• Istället för intellektuellt stimulerande blir arbetet stressigt
• Risken att du kommer att missa viktiga testresultat som finns i slutet av materialet blir uppenbar, eftersom du inte kommer att kunna ägna denna del av materialet samma uppmärksamhet
• Rapporten kommer förmodligen att innehålla onödiga slarvfel eftersom du inte kommer att hinna med de sista genomläsningarna, och detta leder i sin tur till att rapporten kommer att tillmätas lägre trovärdighet

För att undvika dessa problem bör du alltid börja med att lägga *en* timma på att identifiera de 3-5 viktigaste resultaten från testet. Dokumentera både problemen och tänkbara lösningar i rapporten i form av enkla punktlistor.

Beroende på hur mycket tid du har på dig bör du sedan upprepa samma övning 2-5 ggr, och varje gång dubbla analystiden, och därigenom dokumentera fler och mer detaljerade resultat.

När hälften av tiden som du avsatt för analys och dokumentation har gått bör du skifta fokus till att illustrera problemen och de tänkbara lösningarna. Gå igenom punktlistorna och komplettera med flödesbeskrivningar, bilder, pilar och beskrivande texter som både visar problemen och lösningarna. Presentationen är oerhört viktig både för att skapa inlevelse och förståelse, och för att underlaget till de som skall åtgärda problemen sedan skall förstå vad som behöver göras för att det system som testas skall bli bättre.

Rapporten bör avslutas med en lista över de viktigaste av de förslagna förändringarna, prioriterade efter hur stor effekt de förmodas ha.

I rapporten ska aldrig en enskild användares identitet utlämnas, även om de som läser rapporten mycket väl känner användarna. Du kan bifoga schemat, men du ska aldrig beskriva resultat från en viss session och peka ut en enskild individ.

10. Överlämna

Om beställaren inte deltagit i utvärderingen bör du boka tid för en muntlig genomgång med beställaren för överlämning. Innan mötet ska du gå igenom resultatet med projektledaren, som sedan också bör delta i mötet med beställaren. Förklara tydligt vilka frågeställningar som kräver beslut och förklara alternativen.

En presentation av resultatet kan följa denna mall;

1. Beskriv kort tillvägagångssättet.
2. Beskriv de allvarligaste problemen som visade sig. Berätta gärna användarnas reaktioner så blir resultatet enklare att ta till sig. Avslöja aldrig vem som sagt eller gjort vad.
3. Beskriv alternativa lösningar (om din uppgift varit att ta fram lösningsförslag).
4. Om möjligt – fatta beslut. Se till att projektledaren noterar dessa.

För att kunna genomföra ett användbarhetstest behöver du kunskap om produkten och produktområdet, men framför allt behöver du erfarenhet som handledare. Erfarenhet kan du bara få genom övning, så det bästa är om du kan få delta vid ett antal tillfällen då en erfaren handledare utför jobbet. Kunskaper som du bör förvärva är praktisk kunskap att planera, dokumentera och rapportera ett användbarhetstest. Du behöver också kunskap om hur du kan stötta användaren i testtillfället, även då användaren har svårigheter med att slutföra på grund av stress, känsla av otillräcklighet eller annat. Dessa tillfällen är mycket sällsynta, men som handledare måste du kunna behärska dessa situationer. Du måste helt enkelt kunna garantera att de användare som genomgått testet känner sig väl till mods.

Ögonrörelsespårning, eller eye-tracking, är en teknik som gör det möjligt att följa hur användarens ögon rör sig över skärmen. Det innebär att ögonens position och rörelse mäts. Styrkan med eye-tracking är att du får ett objektivt resultat och bevis på vad användaren gör och framför allt vad det är på skärmen som drar till sig användarens uppmärksamhet.

För att mäta ögonrörelserna krävs att du har en speciell skärm som kalibreras för varje enskild användare (det finns även andra tekniker för att mäta ögonrörelser). Kalibreringen tar någon minut innan testet sätter igång och är viktig för att resultatet av mätningen ska bli så korrekt som möjligt. Testet genomförs sen som ett vanligt användbarhetstest.

Nyckeln till att få ett givande resultat av ögonrörelsespårning är förberedelse. Du måste innan testet ha tänkt igenom vad det är du vill visa med ögonrörelsespårningen. Beroende på vilket resultat du är ute efter måste du också forma testuppgifterna därefter. Det blir mer möjligt att jämföra och sammanställa ett resultat om användarna har haft samma förutsättningar. Resultatet från ett ögonrörelsetest kan visas med värmekartor, diagram och siffror, men också med filmsekvenser från testet som visar en enskild användares ögonrörelsemönster.

Fjärrtester, eller ”remote usability testing”.

Utveckla wikin: Fyll på med information om detta ämne.

Användbarhetstest i testlabb kan användas:

• När man är intresserad av att veta om en produkt uppfyller på förhand uppsatta och mätbara krav.
• När det är viktigt att det finns statistiska data.
• När tidskritiska funktioner är viktiga att utvärdera.
• Vid vetenskapliga studier.
• När flera produkter ska jämföras med varandra.

Ett labbtest ger störst nytta sent i utvecklingsprocessen, som en sista kontroll att systemet lever upp till de krav på effektivitet som ställs. Att låta en produkt gå igenom en användbarhetslabb är också relativt kostsamt. En annan nackdel är att testet utförs i en miljö som inte motsvarar den faktiska användningssituationen.

I ett labbtest mäter man oftast kvantitativa faktorer som:

• Hur lång tid tar det att lösa en uppgift.
• Huruvida man löser uppgiften eller inte.
• Hur många problem som uppstod under tiden uppgiften löstes.

Ett vanligt förekommande inslag i denna typ av test är även att låta användarna redogöra för sina subjektiva upplevelser dvs. hur de upplevde produkten. På så vis kan man sedan jämföra resultatet från själva testet (objektiva) med hur de upplevde produkten och på så vis dra vissa slutsatser.

Till skillnad från ett användbarhetstest, som praktiskt taget kan genomföras var som helst, sker ett labbtest i speciella lokaler. I ett rum finns plats för användarna som ska utvärdera produkten. Där finns den produkt som ska utvärderas tillsammans med kameror och mikrofoner. Bakom en genomsiktig spegel finns ett kontrollrum. Härifrån sköter testledarna den tekniska utrustningen som används men det är även vanligt att observatörer och andra personer som har intresse av att vara med finns där. Från kontrollrummet kan man se in i testrummet, men inte vice versa.

Under tiden som användaren löser de uppgifter som testledaren på förhand tagit fram spelas interaktionen mellan användaren och produkten in.

Användarens interaktion med produkten registreras av ett program som skapar en logg av varje knapptryckning, förflyttning och val som användaren gör. Samtidigt som händelserna lagras registreras även en tidskod som sedan kan kopplas till den film som spelas in. På så vis kan testledaren koppla ihop videofilmen med loggfilen och lättare analysera vad som hände.