1 Utvärdering Processen Utvärderingsanvändare ...
1 Utvärdering Processen Utvärderingsanvändare ...
1 Utvärdering Processen Utvärderingsanvändare ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>Utvärdering</strong><br />
<strong>Processen</strong><br />
TNMK31 – Användbarhet<br />
HIIA20 – Användbarhet med kognitiv psykologi<br />
Martin Karlsson marka@itn.liu.se K7522 011 – 36 34 63<br />
2006-04-26 Martin Karlsson - Användbarhet 2<br />
<strong>Utvärdering</strong>sanvändare<br />
<strong>Utvärdering</strong>sanvändare<br />
1<br />
2<br />
3<br />
5 extremanvändare<br />
2-3 extremanvändare, 2-3 ytterligare<br />
1-3 extremanvändare, 2-4 ytterligare<br />
Ny användare av systemet<br />
Kännedom om uppgiften<br />
Bryr sig inte om uppgiften<br />
Expertanvändare av systemet<br />
Användare<br />
Extremanvändare<br />
• Användardeltagande är ”alltid” möjligt<br />
• En ursäkt för att inte ta med användare i<br />
utvärderingsaktiviteten är att de kanske inte<br />
är tillgängliga eller kända<br />
• Liam Bannon berättar en ironisk historia där<br />
han inte var tillåten att träffa en enda<br />
användare ”for political, organizational<br />
reasons”<br />
• ”Surrogatanvändare” står alltid att finna, bara<br />
man är medveten om att man kanske inte ska<br />
tro fullt ut på dem<br />
2006-04-26 Martin Karlsson - Användbarhet 3<br />
2006-04-26 Martin Karlsson - Användbarhet 4<br />
<strong>Utvärdering</strong><br />
• Varför utvärdera alls?<br />
• Alla är inte som du<br />
• Problem fixas före produkten släpps<br />
• Designteamet kan koncentrera sig på verkliga<br />
problem, inte på eventuella tänkta sådana<br />
• Programmerarna kan koda istället för att debattera<br />
hur det ska vara<br />
• Utvecklingstiden minskas<br />
• När produkten släpps så har marknadsavdelningen en<br />
design de kan sälja utan att behöva förklara hur<br />
mycket bättre det kommer att bli i nästa version ☺<br />
<strong>Utvärdering</strong><br />
• Formativ utvärdering<br />
• Stöd för designprocessen<br />
• Arbeta nära presumtiva användare<br />
• Kvalitativa aspekter av systemet<br />
• Summativ utvärdering<br />
• Utvärdera en färdig produkt<br />
• Arbeta med slutanvändare<br />
• Kvantitativa aspekter av systemet<br />
2006-04-26 Martin Karlsson - Användbarhet 5<br />
2006-04-26 Martin Karlsson - Användbarhet 6<br />
1
<strong>Utvärdering</strong>smetoder<br />
• Empirisk metod<br />
• Med användare<br />
• En analys av användarens prestation i relation till det tänkta<br />
systemet<br />
• Arbeta med användare och samla data<br />
med hjälp av intervjuer,<br />
observationer, mätningar, etc.<br />
• Analytisk metod<br />
• Utan användare<br />
• Usability inspection<br />
• Kombinera metoder<br />
• Varje iteration bör bestå av ett antal empiriska och ett antal<br />
analytiska metoder<br />
<strong>Utvärdering</strong><br />
• En generell utvärderingsprocess<br />
har följande struktur:<br />
• Identifiera målgruppen<br />
• Rekrytera användare<br />
• Forma uppgiften<br />
• Genomför utvärderingen<br />
• Rapportera/dokumentera upptäckter/beslut<br />
2006-04-26 Martin Karlsson - Användbarhet 7<br />
2006-04-26 Martin Karlsson - Användbarhet 8<br />
<strong>Utvärdering</strong>smetoder<br />
• Metoder för empirisk utvärdering<br />
• Frågeformulär<br />
• Observationer<br />
• Intervjuer<br />
• Scenarier<br />
• Wizard of Oz<br />
• Tänka högt<br />
• Kognitiv genomgång<br />
• Kontextuell utforskning<br />
• Deltagande design<br />
• Gruppgranskning<br />
• Fokusgrupper<br />
• Kreativitetsmetoder (som<br />
brainstorming)<br />
• Mätningar<br />
• Prestationsrelaterade<br />
• Kritiska händelser<br />
<strong>Utvärdering</strong>smetoder<br />
• Scenarier<br />
• Användningsscenario &<br />
scenariobaserad utvärdering<br />
”A scenario can be used to figure out whether<br />
a certain function in a product is worth<br />
constructing before actually constructing it.”<br />
• Uppgiftsscenario<br />
Syftar till att sätta in användaren i situationen<br />
och specificerar den uppgift som användaren<br />
ska utföra<br />
2006-04-26 Martin Karlsson - Användbarhet 9<br />
2006-04-26 Martin Karlsson - Användbarhet 10<br />
<strong>Utvärdering</strong>smetoder<br />
• Gruppgranskning<br />
• Utförs med användare,<br />
utvecklare och andra<br />
intressenter<br />
• Gruppen går igenom ett<br />
antal scenarier som bygger<br />
på användarnas<br />
arbetsuppgifter<br />
• Man utvärderar varje steg<br />
och kategoriserar samt<br />
värderar problem<br />
• Fördel är att man får<br />
många infallsvinklar<br />
<strong>Utvärdering</strong>smetoder<br />
• Tänka högt-protokollet<br />
• Bäst förståelse för hur användarna tänker är att låta<br />
dem tänka högt under tiden de utför en uppgift.<br />
(Direkt efter uppgiftens utförande är för sent, KTM).<br />
• Användarna bör för varje steg i uppgiften förklara<br />
vad de gör och varför<br />
• Att tänka högt är inte så lätt som det låter och det är<br />
lämpligt att man som utvärderare ser till att<br />
användaren känner sig bekväm med det.<br />
• Alla typer av artefakter kan testas med att tänka högt<br />
2006-04-26 Martin Karlsson - Användbarhet 11<br />
2006-04-26 Martin Karlsson - Användbarhet 12<br />
2
<strong>Utvärdering</strong>smetoder<br />
• Kognitiv genomgång<br />
• Tekniken kommer ifrån systemutveckling,<br />
kodgenomgång är en vanlig metod att hitta<br />
buggar i system<br />
• Både kodgenomgång och kognitiv genomgång har<br />
undermeningen att de är analytiska metoder<br />
• Det är svårt att göra kodgenomgång med användare<br />
eller andra utomstående då de måste förstå<br />
programkod, däremot lämpar det sig mycket bra att<br />
använda kognitiv genomgång med användare<br />
(empirisk metod)<br />
<strong>Utvärdering</strong>smetoder<br />
• Kognitiv genomgång (empirisk metod)<br />
• Består av:<br />
• Uppgiftsscenario<br />
• Tänka högt-protokollet<br />
• Huvudfokus är på hur lätt ett system är att lära sig.<br />
”Learning through exploration.”<br />
• Ställ frågor till användaren om användaren tvekar<br />
• Vad ska man göra i det här läget?<br />
• Hur ska man göra?<br />
• Berättar systemet vad som har gjorts?<br />
(jämför: Visibility, affordance, feedback)<br />
• Utvärdera varje steg i det korrekta uppgiftsutförandet<br />
och utröna varför användaren agerade som hon<br />
gjorde. (Lätt att hitta flaskhalsar)<br />
2006-04-26 Martin Karlsson - Användbarhet 13<br />
2006-04-26 Martin Karlsson - Användbarhet 14<br />
<strong>Utvärdering</strong>setik<br />
• Användare är människor, inte saker<br />
• Tänk över testet noga. Inget får såra/skada<br />
användaren varken psykiskt eller fysiskt<br />
• Kalla inte användaren för försöksperson<br />
• Vad är etiskt? Vad får man<br />
hålla hemligt?<br />
(Milgram’s obedience study)<br />
• Etikregler för forskning<br />
• Informationskravet, Samtyckeskravet,<br />
Konfidentialitetskravet, Nyttjandekravet<br />
<strong>Utvärdering</strong>setik<br />
• Förklara för användaren vad<br />
som förväntas av henne<br />
• Förklara att användaren är fri<br />
att avsluta utvärderingen<br />
närhelst hon vill<br />
• Förklara vad syftet med<br />
utvärderingen är<br />
• ”Det är produkten som testas,<br />
inte du”<br />
• Se till att användaren känner<br />
sig väl till mods<br />
• Förklara att resultaten av<br />
utvärderingen är anonyma och<br />
hur de kommer att användas<br />
2006-04-26 Martin Karlsson - Användbarhet 15<br />
2006-04-26 Martin Karlsson - Användbarhet 16<br />
Användarutvärdering (exempel)<br />
1. Tidsbestämning för utvärdering<br />
2. Lär dig produkten (!)<br />
3. Mottagande av användare, småprat(!) och<br />
bakgrund för utvärdering, produkt och<br />
användare<br />
4. Kognitiv genomgång med uppgiftsscenario<br />
5. Uppföljningsfrågor (intervju) för att mäta<br />
användbarhetsmål<br />
6. Avslutning, tidsbestämning för nästa<br />
utvärderingstillfälle, belöning(?)<br />
Expertutvärdering<br />
• Varför analytisk utvärdering?<br />
• Behöver ej tillgång till användare<br />
• Snabb, billig, kostnadseffektiv<br />
• När utvärderar man?<br />
• När som helst<br />
• Tidiga prototyper eller specifikationer<br />
• För att snabbtesta nya lösningar<br />
• Vad är expertutvärdering?<br />
• Formell utvärdering med användbarhetsexperter, dvs. ni!<br />
• Exempel på expertutvärdering<br />
• Heuristisk utvärdering / dokumentbaserad metod<br />
• Cognitive walkthrough<br />
2006-04-26 Martin Karlsson - Användbarhet 17<br />
2006-04-26 Martin Karlsson - Användbarhet 18<br />
3
Heuristisk utvärdering<br />
• Heuristisk utvärdering<br />
• En del av analytisk metod<br />
• Använder sig av tumregler (heuristiker)<br />
• Team av utvärderare (experter)<br />
• Utvärdera individuellt<br />
• Ranka problem<br />
• Sammanställ resultat<br />
• Tumregler<br />
• Nielsen, Norman, Shneiderman<br />
Heuristisk utvärdering<br />
• Nielsens 10 tumregler<br />
1. Systemets status ska alltid vara synlig<br />
• Systemet ska alltid visa användaren vad som händer<br />
genom lämplig feedback, inom rimlig tid<br />
2. Matcha verkligheten<br />
• Systemet ska tala användarnas språk och följa de regler<br />
och normer som gäller i den aktuella miljön. Information<br />
ska presenteras i en ordning som är logisk för användarna<br />
3. Låt användaren vara i kontroll<br />
• Det ska alltid finnas nödutgångar som användaren kan<br />
utnyttja om han/hon gjort fel eller ångrar sig. Det ska<br />
alltid gå att ångra sig.<br />
2006-04-26 Martin Karlsson - Användbarhet 19<br />
2006-04-26 Martin Karlsson - Användbarhet 20<br />
Heuristisk utvärdering<br />
• Nielsens 10 tumregler<br />
4. Enhetlighet och standarder<br />
• Användaren ska aldrig behöva fundera på om olika ord,<br />
situationer och funktioner betyder samma sak<br />
5. Förebygg problem<br />
• Systemet ska designas så att problem och fel kan undvikas<br />
i möjligaste mån<br />
6. Igenkänning snarare än memorering<br />
• Objekt, funktioner och alternativ ska vara synliga.<br />
Användaren ska inte behöva komma ihåg information från<br />
en dialog till en annan. Instruktioner för användning ska<br />
vara synliga eller lätta att ta fram.<br />
Heuristisk utvärdering<br />
• Nielsens 10 tumregler<br />
7. Flexibilitet och effektivitet<br />
• Snabbtangenter gör att systemet passar både nybörjare<br />
och expertanvändare. Det ska finnas möjligheter för<br />
expertanvändaren att skräddarsy frekventa operationer<br />
8. Estetisk och minimalistisk design<br />
• Dialoger ska inte innehålla information som är irrelevant<br />
eller används sällan. Varje enhet av onödig information<br />
tävlar om uppmärksamhet med den nödvändiga<br />
informationen<br />
9. Hjälp användaren att upptäcka och rätta till fel och<br />
misstag<br />
• Felmeddelanden ska skrivas på ett enkelt språk (inga<br />
koder!), beskriva problemet i detalj samt föreslå lösning<br />
2006-04-26 Martin Karlsson - Användbarhet 21<br />
2006-04-26 Martin Karlsson - Användbarhet 22<br />
Heuristisk utvärdering<br />
• Nielsens 10 tumregler<br />
10. Hjälp och dokumentation<br />
• Det bästa är om systemet<br />
kan användas utan hjälp<br />
och dokumentation, men i<br />
många fall är inte detta<br />
möjligt. Hjälp och<br />
dokumentation ska vara<br />
lätt att hitta i, beskriva<br />
användarens uppgifter,<br />
ange ett antal konkreta<br />
steg som användaren ska<br />
utföra och inte vara för stor<br />
Heuristisk utvärdering<br />
• Ranka problem<br />
• Prioritering enligt tre faktorer<br />
• Frekvens: Hur ofta uppstår problemet?<br />
• Påverkan: Hur lätt är problemet att komma runt?<br />
• Ihärdighet: Är det ett engångsproblem eller ett<br />
återkommande problem?<br />
• Värdera problem enligt prioriteringsfaktorer<br />
och placera på följande skala:<br />
0 = Inget användbarhetsproblem.<br />
1 = Kosmetiskt problem. Behöver endast åtgärdas om tid finns.<br />
2 = Mindre användbarhetsproblem. Låg prioritet att åtgärda.<br />
3 = Större användbarhetsproblem. Hög prioritet att åtgärda.<br />
4 = Användbarhetskatastrof. Måste åtgärdas.<br />
2006-04-26 Martin Karlsson - Användbarhet 23<br />
2006-04-26 Martin Karlsson - Användbarhet 24<br />
4
Cognitive Walkthrough<br />
• Kognitiv genomgång (analytisk metod)<br />
• Fyra saker behövs<br />
• En prototyp<br />
• En uppgiftsbeskrivning<br />
• Ett fullständigt användningsscenario<br />
• En användarbeskrivning eller en persona<br />
• Fyra frågor besvaras<br />
• Kommer användarna försöka utföra uppgiften trots<br />
att problem har uppstått?<br />
• Kommer användarna att inse om de har ”gjort rätt”?<br />
• När användarna hittar ett bra sätt att utföra en uppgift på, kommer<br />
de att inse att det är det bästa sättet?<br />
• När uppgiften utförs, förstår användarna den återkoppling som<br />
systemet ger dem?<br />
Andra analytiska metoder<br />
• Modellbaserade metoder<br />
• Baseras på modeller av användare (ex. Personas)<br />
som teoretiskt möjliggör att man kan förutspå<br />
användarnas beteende<br />
• Baseras mycket på stereotyper och är därför inte<br />
tillförlitliga<br />
• Automatiska utvärderingar<br />
• Utnyttjar algoritmer som fokuserar på<br />
användbarhetskriterier<br />
• Diagnosticerar brister i systemet<br />
• Kräver ett färdigt system, därmed används det oftast<br />
vid summativ utvärdering<br />
2006-04-26 Martin Karlsson - Användbarhet 25<br />
2006-04-26 Martin Karlsson - Användbarhet 26<br />
Råd vid val av metod<br />
• Kombinera metoder<br />
• Olika utvärderingsmetoder bidrar till att finna olika typer av<br />
användbarhetsproblem<br />
• Enkla metoder framför komplexa<br />
• Objektiva, noggranna och kvantitativa mått är onödigt. Bättre<br />
att upptäcka problem och använda tiden för att åtgärda<br />
problemen<br />
• Dokumentera inte för mycket<br />
• Korta listor är bättre än långa dokument<br />
• Håll en positiv ton i utvärderingen<br />
• Inse att all negativ kritik som användarna kan uppbringa är bra<br />
kritik. Se det som konstruktiva förslag<br />
• Använd gärna rankningssystemet för alla funna problem<br />
Avrapportering<br />
• Brist på konstruktiva utvärderingsresultat<br />
• <strong>Utvärdering</strong>ar talar ofta om vad det är för fel<br />
på ett system, men inte vad man ska göra för<br />
att komma tillrätta med problemen<br />
• Utvecklarna är inte särskilt betjänta av ickekonstruktiv<br />
kritik<br />
• Därför bör man inte bara skapa en<br />
prioriteringslista över vad som ska ändras<br />
utan även en handlingsplan för hur det ska<br />
ändras<br />
• Detta passar väl in i användbarhetsguiden<br />
2006-04-26 Martin Karlsson - Användbarhet 27<br />
2006-04-26 Martin Karlsson - Användbarhet 28<br />
Återkoppling till användare<br />
• Riktlinjer för att ge feedback till användarna<br />
• Samla in och dokumentera alla användarsynpunkter<br />
• Tag ställning till alla användarkommenterar och fatta<br />
beslut:<br />
• Att göra förändringar i enlighet med kommentarerna<br />
• Att inte göra förändringar (här är det viktigt att förklara för<br />
användarna varför inte förändringen genomfördes)<br />
• Rapportera beslutet tillbaka till användarna<br />
• Ett designbeslut som får direkta inverkningar på<br />
användarens situation som denne inte känner till eller förstår<br />
kommer att förstöra användarens motivation till fortsatt<br />
deltagande<br />
Sammanfattning<br />
• Jakob Nielsens tre tips för enkel utvärdering:<br />
• Rekrytera representativa användare<br />
• Be dem utföra representativa uppgifter med<br />
prototypen<br />
• Håll käft och låt användarna prata<br />
2006-04-26 Martin Karlsson - Användbarhet 29<br />
2006-04-26 Martin Karlsson - Användbarhet 30<br />
5