Strict Standards: Declaration of action_plugin_indexmenu::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /storage/content/37/152837/anvandbarhet.se/public_html/lib/plugins/indexmenu/action.php on line 13 Strict Standards: Declaration of action_plugin_badbehaviour::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /storage/content/37/152837/anvandbarhet.se/public_html/lib/plugins/badbehaviour/action.php on line 72 Strict Standards: Declaration of action_plugin_clearhistory::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /storage/content/37/152837/anvandbarhet.se/public_html/lib/plugins/clearhistory/action.php on line 81 Strict Standards: Declaration of action_plugin_metaheaders::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /storage/content/37/152837/anvandbarhet.se/public_html/lib/plugins/metaheaders/action.php on line 140 Strict Standards: Declaration of action_plugin_blockquote::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /storage/content/37/152837/anvandbarhet.se/public_html/lib/plugins/blockquote/action.php on line 61 Strict Standards: Declaration of action_plugin_editsections_es::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /storage/content/37/152837/anvandbarhet.se/public_html/lib/plugins/editsections/action/es.php on line 74 Strict Standards: Declaration of action_plugin_swiftmail::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /storage/content/37/152837/anvandbarhet.se/public_html/lib/plugins/swiftmail/action.php on line 126
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:
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:
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:
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:
Ett användbarhetstest är en kostnadseffektiv teknik att fånga hur väl en produkt fungerar i en konkret användningssituation1. 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 19912. 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;
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:
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:
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:
– Ok, hur tror du vi ska göra för att lösa det här?
– Pröva och se vad som händer. – Testa.
– Varför är listan i den här ordningen?
– Har du provat alla ställen?
– Vad tänker du på … – Vad söker du efter …
– Varför gjorde systemet så … – Vad trodde du skulle hända … – Vad tror du händer om … – Vad har systemet gjort nu …
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:
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;
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:
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:
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.
Användbarhet i praktiken - wiki by Ingrid Dominques/Johan Berndtsson is licensed under a Creative Commons Erkännande-IckeKommersiell 3.0 Unported License. Based on a work at anvandbarhet.se.
Kommentera