1

Från användaranalys och uppgiftsanalys till kravställning

Föreläsning 18/9 2003

Kap 1.5, 7, 9, (14) (användaranlys och användbarhetskrav)Kap 2.1 - 2.2, 7, (14) (uppgiftsanalys och funktionalitetskrav)

Förra gången, verktygslådan:

• Metoder för datainsamling• Intervjuer• Observationer• Etnografisk metod• Contextual inquiry• Enkäter

• Metoder för databearbetning• Team analysis• Affinity diagrams• Persona, scenarier och storyboards• Användar/uppgiftsmatriser

Användarcentrerad designmetodik

Analysera användare, användnings-

situation och uppgift

Specificerakrav på

användande

Skapa och kommuniceradesignförslag

(prototyper m.m.)

Testa ochutvärdera

designförslagmed användare

Användaranalys och användbarhetskrav

Användaranalys – lär känna användare

• Kognitionspsykologi ger allmänna kunskaper om människor

• Användaranalys ger specifika kunskaper om en viss grupp

Vem är användaren?

• Vetenskapligt förhållningssätt, alla resultat och slutsatser skall kunna härledas

• Hitta användarattribut (som kan påverka systemutformningen)

2

Olika användargrupper

Domänkunskap

Datorkunskap

Identifiera

• Vilka/vilken är målgruppen?• Vilka/vilken är användningssituationen?• Vilka/vilken är användningsmiljön?

Syfte

Oavsett metod vill man kunna urskilja grupper av användare med liknande bakgrund, arbetsuppgifter och systemkrav

Resultat• Användarprofiler• Designrekommendationer• Input till kravspecifikation

Användaranalys

Svarar på följande frågor:• För vilka? Vilken/vilka är målgrupperna?

• Åldersgrupp, kön, yrkeskategori?• Intressekategori?

• I vilken situation?• Arbetet, fritiden, skolan?...• Stress, tidspress? ...• Inomhus, utomhus, i bilen? ...

forts

• I vilken miljö?• Ljusförhållanden, ljudnivå, andra störningsmoment?• Speciella rum?

• Kompetensnivå• Inom området, datorvana, datorkunskaper?• Allmän kunskap, vad känner de till?• Attityd till teknik?

forts

• Motivation?• Är uppgiften självvald eller inte?• Varför utför de uppgiften?

• Utför de uppgiften/aktiviteten idag?• Hur? (kan finnas många sätt)• Varför gör de som de gör idag?• Varför skulle de vilja ändra sitt nuvarande sätt? Vad förbättras? • Vad bibehållas?• Hur kan man gissa att det nya systemet kan ändra deras

beteende?• Är de motiverade att göra förändringen?

3

Användarna• Handikapp eller speciella behov?• Speciella förmågor?• Begränsningar?• Olika kulturer?• Språk?• Utbildning?• Vana vid arbetsuppgiften?• Allmän datorvana? (vana vid olika system, både professionellt och

privat).• Attityder?

Användningssituationen

• Belastning (stress, kritiska situationer, sinnesstämning)

• Organisatoriskt (ex informationskanaler, beslutsvägar)

• Vad händer för övrigt? (omorganisationer etc)

• Personalomsättning• Hur ofta kommer nya användare?

• Hur vana är de vid arbetsuppgiften?

Användningssituation, forts

• Utför användaren någon annan uppgift samtidigt?• Vad gör användaren i övrigt, när han/hon inte skall arbeta

med systemets uppgift?• Miljö, ljust, mörkt, buller, inomhus, utomhus, starkt soljus,

etc?• Tidspress?• Hur ofta kommer man att använda systemet?

Relation till systemet

•Har användaren haft inflytande?

•Hur viktigt är systemet, gäller det huvuduppgift?

•Kommer systemet att förändra arbetsuppgifterna?

•Hur ofta kommer de att använda systemet?

•Hur lång tid åt gången?

Relation till systemet, forts

• Vilka system använder de idag?

• Vilka system kommer de att använda samtidigt?

• Information om systemet?

• Förväntningar

• Förhoppningar

• Farhågor...

• Kan systemet innebära några risker?

Inför analysen

• Gör helst datainsamlingen (intervjun/observationen/etc) i den miljö systemet ska användas.

• Om du antecknar, erbjud användaren att kontrollera dem i efterhand.

• Be alltid om tillstånd om du planerar att använda bandspelare eller video

• Förklara alltid syftet• Tillstånd, sekretessavtal?

4

Förberedelser

• Kom ihåg att i den här situationen är det användaren som är expert, du är där för att lära av dem!

• Tillfället är INTE en säljsituation!• Försök glömma allt du tror att du vet om hur något ska

lösas! • Läs på, t ex terminologi, lagstiftning

Metoder:

• Intervjuer• Observationer• Etnografisk metod• Enkäter• Fokusgrupper• Contextual inquiry• Concept Engineering• Work shops

Att kravställa på användande

• Användningen av ett interaktivt system är komplex och omfattar flera faser• införande• träning• genomförande

• Uppdelning i fyra kategorier, enligt Bennet och Shackel• I boken finns exempel på en annan uppdelning, se sid 14

Användbarhetskrav

• Learnability• Hur lätt är det att lära sig systemet?• Hur lång tid får det ta att komma till en viss grad av användande?• Hur lång tid tar det att bli expert?

• Throughput• Hur smidigt är systemet att använda?• Kan uppgiften utföras fortare jämfört med dagens system?

Användbarhetskrav

• Flexibility• Om uppgiften förändras, kan systemet följa med?• ”Kan jag göra på mitt sätt”

• Attitude• Användarens subjektiva åsikter• Användarens personliga upplevelser under användning• Vilket varumärke förmedlar systemet

Användarupplevelser

• User experience goals• Centralt för en interaktionsdesigner

• Roligt• Underhållande• Estetisk upplevelse• Kreativitetsskapande• etc

• Beskrivs i kap 1.5.2

• I Bennet och Shackels uppdelning täcks dessa delvis in av attitydkrav.

5

Uppgiftsanalys och funktionalitetskrav

Huvudsyften

Uppgiftsanalys handlar om:• att förstå själva uppgiften eller aktiviteten som det tänkta systemet

skall stödja• att titta på uppgiften/aktiviteten ur alla målgruppers perspektiv

Funktionalitetskrav beskriver• vad ett system skall kunna göra• men inte hur det skall göras

Uppgiftsanalysens mål

• att identifiera den huvuduppgift ( -aktivitet) som ett tänkt system skall stödja (helt eller delvis)

• att förstå vad denna huvuduppgift (-aktivitet) innebär• veta vilka delar/moment den består av• veta hur dessa moment utförs idag

• att identifiera problemområden• att identifiera väl fungerande områden• att förstå vilket mervärde ett tänkt systemet kan ge

Uppgiftsanalysens resultat

• Input till kravspecifikationen (funktionalitetskrav)• genom analys av uppgiftens struktur/delar• genom att studera användares utförande av uppgiften• genom förslag och önskemål från användare

• Designidéer, • inspiration till metaforer och konceptuella modeller genom att

• studera uppgiften mer abstrakt (struktur etc.)• studera olika hjälpmedel, verktyg som används idag

• förslag från användare (krav uttrycks oftast som lösningar)• tillvaratagande av bra designlösningar i existerande system

• Motiveringar• till varför ett nytt system behövs (mervärden!)• till den tänkta funktionaliteten

Uppgiftsanalys –potentiell begreppsförvirring...

Kursbokens begrepp:

förstå problemrymden (kap 2.2)

uppgiftsbeskrivning (task description, kap 7.6)

”uppgiftsanalys” (task analysis, kap 7.7)

Alternativ syn:

”Konceptuell” uppgiftsanalys

olika metoder/verktyg somanvänds i analysarbetet

Samma angreppssätt

Oavsett om man skall designa• ett förbättrat befintligt system,• ett ”nytt” system, eller• stöd för en ”ny aktivitet” (ganska ovanligt)

så är angreppssättet detsamma:• Ingen principiell skillnad om man skall analysera uppgifter/aktiviteter där

det finns befintliga system eller inte• Viss skillnad om man skall utforma ett system för en aktivitet som

människor inte ägnar sig åt idag (mer hypotetiska resonemang, mer föreställningar)

6

Uppgiftsanalysens delar

1. Beskriva uppgiften

2. Analysera uppgiften

Metoder för uppgiftsbeskrivning

(Kap 7.6 i boken)• scenarier• användningsfall (use cases)• essential use cases

Kan användas både för att beskriva befintliga eller föreställda uppgifter/aktiviteter.

Används ofta i kombination, ger olika perspektiv.

Scenarier

• är en informell, berättande beskrivning av en aktivitet, ur en användares perspektiv

• fokuserar på aktiviteten, ej på något system

fördelar:• berättande är ett naturligt sätt för människor att beskriva vad de

gör• bra utgångspunkt för diskussioner• systemoberoende

nackdelar:• konkret, en (representativ?) användares persektiv• kan begränsa (utesluter liknande alternativ)

Användningsfall (use cases)

• är en dialogliknande beskrivning av användare-system interaktion • fokuserar på ”normalanvändandet” (utförandeordning)• varje ”aktör-uppgift” par ger upphov till ett användningsfall

fördelar:• kan vara bra för att utforma konkreta interaktionsflöden långt f ram

i utvecklingsprocessennackdelar:

• förutsätter och är starkt kopplat till ett system• förutsätter givna designlösningar (Ex. Systemet frågar använaren

om namn och lösenord)• alternativa användningssätt utesluts eller kommer i skymundan

Essential use cases• uppgiften beskrivs som en uppdelning:

användarintention, bygger på användarroller – system ansvar

• mer abstrakt än scenarier• försöker undvika de begränsande förutsättningarna i

användningsfallsmetoden

fördelar:• bra för identifiera ansvarsfördelningen mellan användare och

system• tillräckligt abstrakt för att inte förutsätta givna designlösningar

nackdelar:• förutsätter ett system

Metoder för uppgiftsanalys

• HTA (hierarchical task analysis), kap 7.7.1• används mest för att analysera existerande situationer, varför

människor handlar som de gör• delar upp uppgiften i en hierarki av deluppgifter• kan användas på alla abstraktionsnivåer

• GOMS (Goals, operations, methods, selection rules), kap 14.5.1• bygger på teorier om hur människor utför uppgifter

7

Metod för konceptuell uppgiftsanalys

• Vad är målet med uppgiften/aktiviteten?• Vad består uppgiften/aktiviteten av?

• Struktur (deluppgifter, delmoment)• Kognitiva aspekter

• Hur kan uppgiften lösas idag?• Olika metoder• Olika hjälpmedel/verktyg/tekniker• Vad avgör valet av metod?

• Vilka är nackdelarna med dagens sätt?• Vilka är fördelarna med dagens sätt?• Vilka mervärden kan ett tänkt system ge?

Kognitiva aspekter

• Viktigt att veta vilka (del)uppgifter som är• svåra, tidskrävande, vanligt förekommande, tråkiga, nödvändiga,

irriterande, icke önskvärda, ansträngande,...• lätta, välfungerande, onödiga, intressanta, roliga,..´.

• Viktigt att veta vad som händer samtidigt, dvs övriga uppgifter och aspekter i arbetssituationen. • T.ex blir ofta avbruten, stödja samarbete, skydda

sekretessinformation etc.

Hur kan uppgiften lösas idag –studera användare

Tänk på:• Användare gör ofta mer än vad man beskriver• Användare beskriver ofta uppgiften utifrån ett system eller given

instruktion, inte hur den faktiskt går till. • Tyst kunskap!è observera användare ”in action”

• Hur hanterar man fel och problem?

Funktionella och icke-funktionella krav

• Funktionella krav• Vad systemet skall klara av

• Icke-funktionella krav• Andra krav som finns på systemet (och systemutvecklingen)

Se tabellen sidan 238 I boken

Funktionalitetskrav

• är krav på vilka funktioner som skall tillhandahållas (på något sätt) för att uppgiften/aktiviteten ska kunna utföras

• bör vara prioritetsordnade (t.ex nödvändiga, önskvärda, tänkbara)• funktionens berättigande skall vara tydlig från uppgiftsanalysen

Att analysera innebär att...

samla in fakta organisera och kategorisera fakta

prioritera – vad är viktigt?

skapa sig en bild (av användarens situation)

formulera antaganden

kontrollera antaganden (med användare)

tänka vidare – spåna

prioritera – vad är nödvändigt, önskvärt,...

dra slutsatser – hur påverkar detta designen?

8

Olika grad av användarinvolvering: Teoribaserad design

• Perceptionspsykologi• Kognitionspsykologi• Teorier för inlärning och hågkomst• Teorier kring hur människor löser en uppgift / ett problem

Användbarhetsdesign

• Eng. Usability Engineering (sid 181)• Användbarhetskrav i kravspecifikationen• Ta fram flera prototyper• Testa prototyperna• Upprepa till användbarhetskraven är uppfyllda

Kontextbaserad design

• Kap 9.4.2• Designern skall förstå användarens arbetssituation och

arbetsmiljö (etnografiska metoder)• Alla observationer och tester sker i rätt kontext - på

arbetsplatsen

Medverkande design

• Eng. Participatory design• Kallas den Skandinaviska modellen• Pelle Ehn, UTOPIA projektet (sid 306-307)• Teknikerna/systemutvecklarna lär sig arbetsuppgifterna• Användarna är aktivt med och påverkar designval under

systemutvecklingen

Video

• Pelle Ehn et al, UTOPIA