Användaranalys och användbarhetskrav

Transkript

1 Från användaranalys och uppgiftsanalys till kravställning Föreläsning 18/ Kap 1.5, 7, 9, (14) (användaranlys och användbarhetskrav) Kap , 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 Testa och utvärdera designförslag med användare Analysera användare, användningssituation och uppgift Skapa och kommunicera designförslag (prototyper m.m.) Specificera krav på användande Användaranalys och användbarhetskrav Användaranalys lär känna användare Vem är användaren? Kognitionspsykologi ger allmänna kunskaper om människor Användaranalys ger specifika kunskaper om en viss grupp Vetenskapligt förhållningssätt, alla resultat och slutsatser skall kunna härledas Hitta användarattribut (som kan påverka systemutformningen) 1

2 Olika användargrupper Identifiera Domänkunskap Vilka/vilken är målgruppen? Vilka/vilken är användningssituationen? Vilka/vilken är användningsmiljön? Datorkunskap Syfte Användaranalys Oavsett metod vill man kunna urskilja grupper av användare med liknande bakgrund, arbetsuppgifter och systemkrav Resultat Användarprofiler Designrekommendationer Input till kravspecifikation 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 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? 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? 2

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 Inför analysen 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? 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? 3

4 Förberedelser Metoder: 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 Intervjuer Observationer Etnografisk metod Enkäter Fokusgrupper Contextual inquiry Concept Engineering Work shops Att kravställa på användande Användbarhetskrav 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 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 Användarupplevelser 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 User experience goals Centralt för en interaktionsdesigner Roligt Underhållande Estetisk upplevelse Kreativitetsskapande etc Beskrivs i kap I Bennet och Shackels uppdelning täcks dessa delvis in av attitydkrav. 4

5 Huvudsyften Uppgiftsanalys och funktionalitetskrav 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 Uppgiftsanalysens resultat 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 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... Samma angreppssätt 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 som används i analysarbetet 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) 5

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 Användningsfall (use cases) ä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) ä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 fram i utvecklingsprocessen nackdelar: 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 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 bygger på teorier om hur människor utför uppgifter 6

7 Metod för konceptuell uppgiftsanalys Kognitiva aspekter 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? 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 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 Hur hanterar man fel och problem? 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 skapa sig en bild (av användarens situation) prioritera vad är viktigt? 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? 7

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 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 ) Teknikerna/systemutvecklarna lär sig arbetsuppgifterna Användarna är aktivt med och påverkar designval under systemutvecklingen Video Pelle Ehn et al, UTOPIA 8