Lektion 11

Ska hjälpa till att lösa problemet: Det första kravet som man kan ställa är att programmet ska kunna lösa uppgiften. Även om det har många fel och brister så kommer folk att använda det om det är bättre än alternativen. Om det inte löser problemet så kommer ingen att använda det oavsett hur lättanvänt det är.
Effektivt: Programmet ska vara effektivt att använda ... sedan kan man ju fråga sig vad som menas med "effektivt"
Tillfredsställande: Systemet ska i någon mening vara "tillfredsställande" att använda.

Hur mäter man "bra'heten"?

Om man inte på nåt vis kan mäta de tre kriterierna så blir det svårt att övertyga andra om nödvändigheten med användbarhetsstudier och att en lösning skulle vara bättre än en annan. Frågan är bara: hur ska man mäta en sådan sak som "tillfredsställade"?

Hjälpa till att lösa problemet

Genom att dela in detta i olika delar som man kan mäta så får man ett sorts mått på hur väl det fungerar. Notera de vaga orden som jag använder, det är inte säkert att detta säger hela sanningen.

Förhållandet lyckas/misslyckas: Man kan ju naturligtvis kolla om man klarar av att lösa en uppgift men vanligtvis så består uppgiften ett antal olika deluppgifter. Man kan då mäta hur man lyckas med de olika deluppgifterna, hur ofta man måste göra om olika saker, etc.
Vilka kommandon används?: Om man tittar på några vanliga system så ser man att flera olika system har en stor mängd olika kommandon och möjligheter ... men att bara ett fåtal av dessa kommandon används av användarna. Genom att mäta vilka kommandon som används (och eventuellt hur de används) så finner man kanske att det är vettigt att ställa sig frågan "Ska verkligen alla dessa kommandon implementeras?", "Blir systemet enklare att använda om jag kan strunta i dessa kommandon?", "Blir systemet stabilare om jag tar bort dessa kommandon?"
Vilka problem har användarna?: Genom att kolla upp vilka problem som användarna har så borde jag få viktiga ledtrådar om vad som behöver förbättras i systemet.
Hur ser resultatet ut?: Det som kommer ut från systemet, av vilken kvalitet är det? Hur mycket av kvalitén beror av systemet?

Effektivt

Att något är effektivt torde ju vara positivt i någon bemärkelse men hur mäter man effektivitet? Är det tiden det tar att slutföra en uppgift eller Š ? Överhuvudtaget gäller det att man tänker efter vad det är man igentligen mäter när man mäter och vad är det man vill få fram.

Tiden det tar att slutföra en uppgift

Säger visserligen någonting men säger det allt.

Hur många steg det tar att slutföra en uppgift

Hur många del-steg tar det att slutföra en uppgift.

Hur mycker behöver man kolla i manualen?

Om en uppgift tar 5 minuter att lösa och en van användare spenderar 2 av dessa att läsa i manualen betyder det då att programmet är dåligt designat eller att det var en ovanlig uppgift?

Hjälpfunktioner

Vad betyder det att man spenderar mycket tid att titta i hjälpfunktionen.

Felhantering

Hur mycket tid spenderar man att kolla upp olika fel man gjort och vad innebär det?

Vad är ett fel?: Gillar Lewis och Normans definition bäst, speciellt detta med error och slips.
Olika typer av fel: I boken listar man 4 olika typer av fel.

Tillfredsställelse

Hur mäter man detta? Vad betyder det att användarna säger att de är nöjda? Om de är missnöjda, vad är de missnöjda med, vad är det de förväntar sig från systemet?

Lärbarhet

Hur mäter man det? Hur lång tid tar det att lära sig systemet? Vad innebär "lärbarheten" för systemet och hur man uppfattar det? Vilka system behöver man lära sig? Vilka system ska man kunna använda "utan att lära sig"? "Knowledge-in-the-world"

Hur ska man lägga upp inlärningen: Om man designar ett komplext system hur ska man konstruera det så att det är lätt att lära, flexibelt, kraftfullt och man snabbt kan använda till nåt nyttigt?

Flexibilitet

I boken nämns flexibilitet men det finns inte någon riktigt bra definition av vad som menas. Men det är alltid trevligt med ett system som klarar av saker som det inte riktigt var designat för ... men hur tar man in det i design/utvärderingsprocessen?

Användbarhetsspecifikation

För att veta vad man ska kolla, hur det ska kollas, vad som är OK, etc

Målgrupp

Vilken/vilka målgrupper har systemet? Tänk både på primära och sekundära användare.

Förutsättningar

Vilka förutsättningar gäller för att man ska använda systemet? T.ex. omgivningen, normala krav på snabbhet, störmoment.

Vad är det man ska mäta?

Hur ska man mäta det?

Beskriv hur man mäter olika saker? Tid? Fel? etc

Vad räknas som godkänt/inte godkänt

Se 129-130

Värsta fallet: Vad är det absolut värsta resultatet?
Minsta nivå för OK: För att man ska kunna säga att systemet är "nåja, OK"
Planerad nivå: Det är hit man vill komma.
Bästa möjliga nivå: Det som är det bästa möjliga man kan få ... kan vara ouppnåbart.
Nuvarande nivå: Hur ser det ut nu?

Vad gör man med resultaten

Personligen tycker jag det är bra att ha tänkt igenom vad man ska använda resultaten till och hur man ska tolka dem ... kan man inte använda dem och inte tolka dem torde det inte vara nån mening att samla in dem!!

Göra själva utvärderingen

När ska man göra själva utvärderingen?

Personligen skulle jag vilja säga "utvärderingarna". Det beror ju naturligtvis på själva utvecklingsprocessen och hur den ser ut men det finns säkert flera "naturliga" punkter i utvecklingen där man kan göra olika former av utvärdering. Tänk t.ex. på hur man kan använda pappersprototyper, storyboards, scenarion för att på olika sätt testa hur systemet fungerar.

Analytisk utvärdering

Görs med "papper och penna" av en "expert", se t.ex. uppgiftsanalys. Har naturligtvis sina begränsningar men kan vara ett "billigt" alternativ.

Empirisk utvärdering

Man kollar direkt på försökspersoner hur systemet fungerar (man kan göra detta med olika former av prototyper, samt olika nivåer av färdigt system).

Fördel

Man kollar ju faktiskt på hur olika personer reagerar på systemet.

Nackdelar

Kan vara kostsamt i form av tid och resurser.

Tar lång tid

Själva experimentet/studien går ofta ganska fort men förberedelser och analys kan ta mycket tid.

Förberedelser

Vad är det igentligen som man vill studera?
Hur mäter man detta?: Tänk igenom på vilka olika sätt man kan mäta det som man vill veta. Ta tid, kolla anteckningar, logga fel är vanliga metoder men ofta vill man veta varför användaren gör som han/hon gör och då blir det lite knivigare. Tänka-högt? Analys av vad användaren gör? Intervjuer? Enkät?
Förbereda matrialet
Kontrollera att man har tänkt igenom allt: Om man gör en studie men inte tänkt igenom vad det
Pilotstudie: Innan man kör det "riktiga" testet bör man göra en "pilot studie" där man kollar att testet i sig är OK genom att låta några personer testa testet.
Vilka ska testa systemet: Det största problemet: att få tag i personer som kan/vill ställa upp och testa systemet.
Skriva instruktioner: Skriv ner instruktioner till den som ska administrera testet, göra testet och utvärdera testet.
Registrera data: Hur ska man kunna registrera data? anteckningar? ljudinspelningar? video?

Utförande

Förklara vad som kommer att hända, syftet (ibland måste man "frisera" detta för att inte störa själv experimentet), vad som kommer att hända med informationen, etc. Försök sedan att göra experimentet utan störningar (såvida inte dessa ingår i experimentet 8-) eller att ge olika information till olika användare (se punkten med att skriva ner instruktionerna)

Utvärdering

Utvärderingen kan ta lång tid om man inte har förberett experimentet noggrannt. Om man har samlat in "rätt" information och inget oförutsett inträffat (händer alltid

) så går det relatativt smärtfritt. En rapport som sammanfattar hela studien och drar några slutsatser avslutar studien.

Sendast modifierad 2000-10-03 av jem (jem@cs.umu.se)