Användaranalys och användbarhetskrav

Relevanta dokument
Designmetodik - Analys och kravställning. 9 oktober 2002

Analysfasen. Systemering med användarfokus

Kravställande/kravhantering

Vad är design? Designmetodik. Varför en metodik? Samma (5!) huvudmoment. Härledning av form från specifikation. Användarcentrerad designmetodik

Föreläsning 3 Användare, uppgift och omgivning. Kapitel 3-4 i Stone et al.

Metoder för datainsamling

Föreläsning 5: Fastställa krav varför, vad och hur

Föreläsning 4 Identifiera krav och behov. Att läsa: Kapitel 10 i Rogers et al.: Interaction design

Nätkurs Design & konstruktion av användargränssnitt 1MD113 Sid 1 (5) Lektion 11 Användare, uppgifter och krav del

Systemering med användarfokus

Uppsats i MDI En reflektion över designarbetet i tidigare inlämningsuppgift

Fö 2: Designprocessen. Projektet. Design är... Forts. projektet

Designmetodik. Användarcentrerad systemutveckling. 2 oktober 2002

Arbetsuppgifter. Vad gör du? Egentligen? Vad behövs? Gruppincheckning

Att fastställa krav. Annakarin Nyberg

Föreläsning 4: Designprocessen

Agenda. Inledning, teoretiska metoder Hierarkisk uppgiftsanalys, HTA Cognitive walkthrough CW Heuristisk evaluering

Föreläsning 12 Inspektionsmetoder. Rogers et al. Kapitel 15

Användarcentrerad systemdesign

Föreläsning 2: Datainsamling - Observation, enkät, intervju. Att läsa: Kapitel 2 och 3 i Stone et al.: User Interface design and evaluation

Föreläsning 3: Mer om utvärdering, Inspektionsmetoder kan man utvärdera utan användare?

Föreläsning 2: Datainsamling - Observation, enkät, intervju. Att läsa: Kapitel 2 och 3 i Stone et al.: User Interface design and evaluation

Användbarhet. Datorbaserade verktyg används till att. Aspekter på användbarhet. uppfylla behov eller lösa problem! Användbarhet.

Användbarhet och Webbutveckling för mobila enheter. Behovsanalys

Handläggningssstöd för synskadade Baserat på teorierna av Constantine & Lockwood

Föreläsning 8, Design

Interaktionsdesign som profession. Föreläsning Del 2

Interaktionsdesign och användbarhet Personas. Paper prototyping. » Metod för representation av användaren. » Metod för konceptutveckling

Föreläsning 2: Datainsamling - Observation, enkät, intervju. Att läsa: Kapitel 2 och 3 i Stone et al.: User Interface design and evaluation

Uppgiftsanalys och användbarhetskrav Del 1 Kravformulering Av Stefan Blomkvist

Stöd för att skapa intuitiva användargränssnitt

Utvärdering. 6 november 2002 Kap 10-11, , 13.5

Personlig reflektion över designarbetet. Av Anneli Olsen, ,

Föreläsning 2: Datainsamling - Observation, enkät, intervju. Att läsa: Kapitel 7 i Rogers et al.: Interaction design

Utvärdering. Övergripande (1) Med/utan användare. Övergripande (2) Fredag 1 oktober F1. Ann Lantz - Anna Swartling -

Föreläsning 4, Användbarhet, prototyper

Design för användbarhet Användarcentrerad utvecklingsprocess

Projektuppgift i Användarcentrerad Systemdesign, ht 04

Användarcentrerad systemdesign

Människa-datorinteraktion 1MD016, hösten 2011 Användarcentrerad systemdesign september 2011

Föreläsning 10: Introduktion till utvärdering. Rogers et al. Kapitel 12

1. (3p) Inom MDI-området framhåller man att människor lär sig via metaforer. Hur menar man att detta går till?

Operatörer och användargränssnitt vid processtyrning

Design för användbarhet

LOGISTIKSYSTEM FÖR SNABBA HJULET AB UTVECKLINGSPROCESS BASERAD PÅ DR. DEBORAH J. MAYHEW S THE USABILITY ENGINEERING LIFECYCLE

Test och utvärdering - introduktion. Systemering med användarfokus Malin Pongolini

Introduktion till kursen Människadatorinteraktion Maria Redström Patricija Jaksetic CR&T

Metoder för datainsamling, ett urval. Intervjuer delar

Redigeringsteknik och postproduktion

Föreläsning 1: Interaktionsteknik, Introduktion. Att läsa: Kapitel 1-2 i Rogers et al.: Interaction design

Reflektioner kring designprocessen av Intellitic

Utvärdering. Övergripande (1) Övergripande (2) Med/utan användare. Heuristisk utvärdering. Expertutvärdering. Måndagen den 29 september 8-10 F1

Frågetekniker. Föreläsning 3, Utvärderingstekniker MDI, Lena Palmquist 1. Än en gång: JEdit (Py Kollberg) Loggning. Tolkande dataanalys

Datainsamling Hur gör man, och varför?

Användarcentrerad systemdesign introduktion till begrepp, processer och arbetssätt

Grupparbete ACSD Projektplanering för ett Patientjournalsystem

Olika syften. TDDD60 användbarhetstest. När passar vilken typ? Med eller utan användare

3/30/12. Föreläsning 2: Datainsamling - Observation, enkät, intervju. Stjärnmodellen. Översikt. Analys. Prototyper Krav. Design

När m an betraktar begreppet användbarhet m åste m an ta hänsyn till två viktiga faktorer. Dessa är:

Avdelningen för Människadatorinteraktion

Föreläsning 7: Kognition & perception

Design och Prototyping

Föreläsning 5 Konceptuell design och designprinciper. Kapitel 8-9 i Stone et al.

Effektivt Nyttigt Självförklarande Kräver ingen manual Intuitivt Läcker design Vem som helst kan använda det. Ändamålsenligt. Farmor kan använda den!

Föreläsning 2: Introduktion till utvärdering varför ska vi utvärdera?

Operatörer och användargränssnitt vid processtyrning

Intro utvärdering

Datainsamling. Daniel Bosk. data.tex :33:45Z danbos

Fö 8. Sammanfattande föreläsning MAMN25

Föreläsning 2: Introduktion till utvärdering varför ska vi utvärdera?

Inlämning 1 - Tentafrågor. Projektgrupp A

Frågor och svar till tentamen i Kravhantering

Design och konstruktion av användargränssnitt (distans) Avdelningen för Människadatorinteraktion. Gulan Jan Gulliksen Ph D, MSc

Objektorientering. Grunderna i OO

Sveriges innovationsmyndighet

Utvärdering av gränssnitt särskilt befintliga. Hur utvecklar man användbara system? Användbarhet handlar om kvalitet

Krav- och Uppgiftsanalys

Användarcentrerad Systemdesign

Föreläsning 2: Datainsamling - Observation, enkät, intervju. Att läsa: Kapitel 7 i Rogers et al.: Interaction design

Designmetodik. Systemering med användarfokus Malin Pongolini

Projekt 4 - FlyttIT Rådgivning och hjälp vid flytt

Fö: Användbarhetsutvärdering

Så säkerställer du affärsnyttan för dina produkter

Prototyping. Planera och genomföra webbproduktionsprojekt. Innehåll. Fördelarna med Pappersprototyper. Lofi-prototyp. Prototyping

Eventuella felaktiga svar kanselerar motsvarande mängd rätta svar

Upplägg. Fö: Användbarhetsutvärdering. Heuristisk utvärdering. 10 heuristiker (Nielsen) Hur många utvärderare?

Människa-Datorinteraktion

2D vs 3D? Nya gränssnitt för processindustrins kontrollrum En pilotstudie

Fastställa mål. Daniel Bosk. goals.tex :33:45Z danbos

Problem 1-1,5p Två av följande metoder för kravspecifikation är ej lämpade att använda vid ett COTSprojekt,

Agila Metoder. Nils Ehrenberg

Granskning av gränssnitt. Mattias Arvola

Vad vi pratade om förra gången. Fast med andra ord

Systemet och användaren En arbetsplatsstudie av upphandlingshantering på Visma Commerce

Observationsmetoder. IT-universitetet MariAnne Karlsson

We cannot solve our problems with the same kind of thinking we used when we created them

UPPSALA UNIVERSITET Projektuppgift Institutionen för informationsteknologi Ht 2004 Användarcentrerad systemdesign.

Användarcentrerad Systemutveckling

Chaos om datorprojekt..

Rätt sak till rätt sak. Uppgiftsanalys. Människan är anpassningsbar. Varför uppgiftsanalys? (?)

Transkript:

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 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

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

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

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 1.5.2 I Bennet och Shackels uppdelning täcks dessa delvis in av attitydkrav. 4

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

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 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 6

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

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 8