USABILITY Session 2 Dataindsamlingsmetoder Brugerne og deres opgaver

Vandfaldsmodellen Kravspecifikation Design Kodning Afprøvning Vedligeholdelse

Iterativt design Identificér behov og krav (Re)Design Brugertest og evaluering Prototyping Færdigt produkt

Stjernemodellen Evaluering OpgaveanalyseImplementering KravspecifikationPrototyping Konceptuelt design

Evaluering Finde ud af om systemet virker Diagnostisk vs. måleevaluering Tidlige evalueringer Sene evaluering

Dataindsamlingsmetoder Empiriske metoder Ikke-empiriske metoder

Samtale med et privat kamera

Fælles udforskning

Fokusgrupper

Brugerworkshopper

Tænke-højt rapporter

Hændelses-rapporter

Funktionschecklister

Logning af systembrug

Feltobservationer

Direkte vs. indirekte observation

Spørgeskemaer

Interviews

Værdifastsættelsesmetoden

Kontrollerede eksperimenter

Målgruppen og dens egenskaber Målgruppen: Hvem henvender produktet sig til Hvad karakteriserer denne gruppe?

Brugeregenskaber relevante for UI design Alder Køn Kultur Fysisk evner og handicaps Uddannelsesmæssig baggrund og domæneviden IT erfaring Motivation Holdninger

Brugerprofilering: Dankortautomat Alder KønMænd og kvinder Fysiske begrænsningerKan have fysiske begrænsninger: hørelse, syn, mobilitet, brug af hænder, kørestol Kan have varierende højde Uddannelsesmæssig baggrund Kan have minimale uddannelsesmæssige kvalifikationer og besidde begrænset talforståelse og evne til at læse/skrive Computer/IT erfaringKan have ingen eller begrænset erfaring i brug af computere MotivationKan være meget motiveret til at bruge Dankortautomaten, særligt hvis man kan udføre transaktionen hurtigt uden at skulle stå i kø i banken HoldningHoldningen til anvendelse kan variere afhængigt af automatens services, pålidelighed og brugerens holdning til computere

Personaer Fiktive brugere Modelleres over generelle karakteristika Bruges til rollespil ved fx. brainstorms om funktioner som brugerne vil have i fremtiden Holder de vilde ideer i tøjler men åbner for kreative tanker Focus på brugeroplevelsen gennem indlevelse i brugeren

Fra egenskaber til krav BrugeregenskaberUI krav Alder: Skærmen skal kunne bruges af folk med forskellig højde Kan have fysiske begrænsninger Skal kunne bruges af gående såvel som kørestolsbrugere eller folk med stokke. Skal tage hensyn til gigt i hænderne Kan have problemer med hørelsen Der skal være både visuel og auditiv feedback på al brugerinteraktion Etc....

Behov Oplevede behov Udtrykte behov Normative behov Lyt til brugerne!

Mål, opgaver og handlinger MÅL Opgave Handling

Opgaveanalysen Skabe en klar forståelse af hvad et system skal hjælpe med at udføre - FORMÅLET! Analyseres hierarkisk - dekomponeres så langt ned det er nødvendigt Typiske spørgsmål: –Hvilke informationer er nødvendige? –Hvad starter en opgave? –Hvad sker med det, som skabes? –Afhænger den af andre opgaver? –Hvad kan gå galt? –Artifakter til omgåelse af uhensigtsmæssigheder

Opgave karakteristika Variationen i opgaverne fra gang til gang ? Hyppige, lejlighedsvise eller bare en gang? Nødvendig viden og færdigheder ? Påvirkninger fra omgivelserne? Tidskritiske opgaver ? Sikkerhedskritiske opgaver ? Alene eller i samarbejde ? Mange opgaver på samme tid (multi-tasking) ?

Use cases og scenarier Opgavescenarie: Narrativ, personlig og specifik beskrivelse af opgave, som den nu udføres Konkret use case: Detaljeret, depersonaliseret beskrivelse af en opgave som den udføres nu, delt op i bruger og system Essential use case: Generel beskrivelse af opgave, med fokus på brugerens intentioner, delt op i bruger og system Use scenarie: Detaljeret beskrivelse af forventet, kommende opgaveudførelse

Use Case: Dankort BrugerhandlingerSystem respons 1) Indsætter kreditkortSpørger efter PIN-kode 2) Indtaster PIN-kodeBekræfter brugerens ID Spørger hvor meget der ønskes hævet 3) Vælger beløbTjekker konto Spørger om der ønskes kvittering 4) Svarer ja eller nejBeder brugeren fjerne sit kort 5) Fjerner kortUdbetaler penge 6) Tager pengePrinter kvittering 7) Tager kvitteringFarvel og tak!

Kognitiv gennemgang Vælg en opgave og skriv ned, hvilke handlinger, opgaven omfatter For hver handling: Brugeren prøver at finde ud af, hvilken handling der vil hjælpe ham til at udføre opgaven Brugeren vælger den handling, som virker rigtigst Brugeren tolker systemets respons og vurderer om han er kommet videre i løsningen af opgaven

Kognitiv gennemgang Er den korrekte handling tilstrækkelig klar for brugeren? Nej, uklart hvordan kortet skal vendes (op/ned forkant/bagkant) Vil brugeren forbinde beskrivelsen af den korrekte handling med det hun forsøger at gøre? Ikonet for indsættelse af kortet er for abstrakt Vil brugeren vide om hun har gjort det rigtigt eller forkert på baggrund af systemets respons? Ja delvist, kortet spyttes ud hvis det vender forkert. Men det er stadig ikke klart om det er forkert på op/ned eller forkant/bagkant dimensionen.

Mentale modeller Modeller, som folk har af dem selv, andre, omgivelserne og tingene de bruger. Man danner mentale modeller gennem erfaring, træning og instruktion –Ofte ubevidste, "tavs viden" –Personlige –Ufuldstændige og ofte fejlbehæftede –Ustabile, henfalder hvis de ikke bruges –Dårligt afgrænsede, ofte sammenblandinger –Uvidenskabelige og overtroiske –Statiske - hellere udføre ekstra arbejde end ændre mentale modeller

Mentale modeller og usability MM hjælper til at navigere i verden gennem effektive forudsigelser Eksisterende MM bruges når man møder et nyt system Hvis MM ligner systemet: let at lære Vægte hensynet til lighed med MM og radikal innovation

Strukturelle og funktionelle MM Strukturelle MM: –Brugeren ved, hvorledes systemet fungerer –Kontekstuafhængige –"Nørd"-agtige: Kan bruge systemet til at løse mange opgaver, "presse systemet" Funktionelle MM: –Brugeren ved, hvorledes systemet anvendes –Kontekstafhængige –Muliggør effektiv løsning af bestemte opgaver med et minimum af mental anstrengelse

At forstå brugernes MM Svært pga af deres natur (ubevidste, ustrukturerede etc.) Kan ikke afdækkes gennem eksplicit at spørge til dem Må udledes af interviews, fokusgrupper, observationer etc. Interaktionen mellem et system og brugeren fortæller noget om forskellen mellem designerens MM og brugeren MM