Usability (brukskvalitet) Engineering

Transkript

1 Usability (brukskvalitet) Engineering Grad av aksept vs. brukskvalitet vs. brukervennlighet Brukskvalitet lett å lære og husk (learnability, memorability) effektiv og feilfri bruk (efficiency (vs. effectivity), errors) likandes (satisfaction) Brukskontekst - hvem er og hva gjør brukeren ferskinger, av-og-til -brukere og eksperter plikt vs. personlig glede tid og ressursbruk Kunnskap og erfaring generell bruk, systemet selv og domenet

2 Kjenn brukeren Livssyklus... brukerkarakteristika nåværende og fremtidige oppgaver Forbedringspotensiale hva eksisterer av teknologi og produkter hva er deres styrker og svakheter Målsetting for utvikleren: mål for ønsket brukskvalitet for ledelsen: økonomisk analyse og gevinst

3 Krav til systemet Skal sikre at systemet blir vellykket Brukbarhetskrav - ofte oversett, men vesentlig: opplæringstid og -ressurser ytelse muligheter for tilpasning aura / holdningsformidling Krever analyse av brukerne / stakeholders Brukssituasjonen/omgivelsene er viktige Kvantitative mål (usability metrics) er nødvendige Evaluering og krav er to sider av samme sak

4 ...livssyklus... Design parallell utforskning av muligheter brukerdeltagelse helhet, konsistens, koordinering Analytisk evaluering generelle og spesifikke prinsipper, retningslinjer og regler heuristisk ekspertvurdering Prototyping ulike typer for ulike formål kostnad vs. nytte

5 Den rekursive diamanten ne opp for muligheter Gjøre begrunnede valg Idé Produkt Tid

6 Prototyping Horisontale vs. vertikale funksjonalitet egenskaper scenario/ storyboards totalsystemet Høy- vs. lav-realisme (fidelity) prototyper papirprototyper, mock-ups, Wizard-of-Oz Verktøy tegneverktøy (Photoshop, Powerpoint, Visio, VB) multimedia/animasjonsverktøy (Macromind Director, QT) database- og RAD (Access/VB, Visual Studio, Delphi)

7 Prediktiv evaluering Vurdere et design basert på generell og spesifikk designkunnskap ekspertgjennomgang eller brukssimulering heuristisk evaluering (kognitiv) gjennomgang (walkthrough) standard- og konsistenssjekk Ekspertgjennomgang og (kognitiv) gjennomgang eksperter simulerer ekte brukere identifiserer problemere ved design og foreslår løsninger må kjenne brukergruppen og de relevante oppgavene nøytralitet, balanse og bredde er vanskelig å oppnå

8 Heuristisk evaluering Eksperters analytiske vurdering av designforslag domeneeksperter, dataeksperter, dobbel ekspertise prinsipper, retningslinjer og regler med eller uten kontekst Analysere flyt gjennom systemet overgangen mellom skjermbilder dialogsekvensiering Analysere hvert skjermbilde, dialog, melding osv. mot tommelfingerregler (heuristikker) Finner de fleste og viktigste feil med 5-10 eksperter

9 Tommelfingerregler for design Enkel og naturlig dialog Snakk brukerens eget språk Reduser belastningen på brukerens hukommelse Konsistens Tilbakemelding Tydelig merket vei ut/tilbake Snarveier/hurtigtaster Gode feilmelding Unngå feil Hjelp og dokumentasjon

10 ...livssyklus Empirisk evaluering syntese (formative) - hva virker (ikke) eller analyse (summative) - sammenligning (alternativer/mål) pålitelighet og validitet (vs. verifisering og validering) testdeltagere testbrukere eksperimentledere observatører etikk testbrukeren er ingen kanin bruk av datamateriale Iterativ design - prøv igjen!

11 Use-case vs. Scenarier Et use-case med flow of events kan utvides i detaljrikdom til å bli et scenarie med en storyboard. UML mangler kontekstinformasjon og mulighet til å være konkret. Scenarier med brukerkarakterer og storyboarding gjør use-casene lettere å kommunisere til bruker, og gir et rikere bilde. Teknikken lar seg greit integrere i RUP.

12 Arkitektur- vs. konseptuell modell Arkitekturer beskrives i RUP vha. UMLs klasser, objekter, etc. Denne formalismen lar seg benytte til å utrykke den modellen bruker skal behøve å forstå. En slik formalisert konseptuell modell har store likhettrekk med businessmodeller og domenemodeller. RUP har formelt apparat til å håndtere det meste av dette. Resten må skje med prosa.

13 Testing vs. brukbarhetstesting Test begrepet i RUP er knyttet til tekniske tester av funksjonalitet. RUP har i utgangspunktet ikke plass til iterative løkker tidlig som gjør brukbarhetstester direkte mot sluttbruker vha. billige prototyper. Dette kan sees på som en del av teknikker som benyttes i requirements. RUP er svak på dette. Preges av Software Engineering, men er på vei mot User-Centered Design i RUP 2000.

14 MMI-forelesninger Overordnet bilde av mennesker (aktører), oppgaver, informasjon og systemer (verktøy) Brukskvalitet Iterativ design og Usability Engineering Evaluering Oppgaveanalyse og modellering Scenariobygging Designteknikker

15 Evaluering Enhver innsamling av data for vurdering av brukskvalitet Elementer ved evaluering karakteristika for (tenkt) brukergruppe oppgaver som utføres omgivelser for evaluering produkt som testes Relevant for alle typer evalueringer

16 Evaluering forts. 4 typer grunner forstå naturlige arbeidsomgivelser sammenligne designforslag design mot brukbarhetskriterier verifisering mot design/produkt-standarder Hva betyr dette for bruker, oppgaver, kontekst, produkt? 2 roller i utviklingen formative mål at designet skal påvirkes av evalueringen summative vurdere ferdig produkt, f.eks. mot standarder

17 Evaluering forts. 2 faser i designprosessen grønn og rød fase Grønn fase validering av oppgaver og andre brukerkrav idegenerering, stimulere til forslag, se hva som virker vurdering av brukskvalitet, prediksjon Rød fase konkrete bruksproblemer (så tidlig som mulig) raffineringer, justeringer iht. observasjoner forbedre oppgradering

18 Evalueringsteknikker Observasjon og monitorering fange opp interaksjon kvalitativ eller kvantitativ datainnsamling Meningsmåling direkte innsikt i oppfatning og følelser satisfaction vs. efficiency Eksperimenter og benchmarking kontrollerte basert på hypotese Undersøkende (interpretative) bruk av eksisterende systemer/teknologi i naturlig omgivelser

19 Prediktiv evaluering Vurdere et design basert på generell og spesifikk designkunnskap ekspertgjennomgang eller brukssimulering heuristisk evaluering (kognitiv) gjennomgang (walkthrough) standard- og konsistenssjekk Ekspertgjennomgang og (kognitiv) gjennomgang eksperter simulerer ekte brukere identifiserer problemere ved design og foreslår løsninger må kjenne brukergruppen og de relevante oppgavene nøytralitet, balanse og bredde er vanskelig å oppnå

20 Heuristisk evaluering Eksperters analytiske vurdering av designforslag domeneeksperter, dataeksperter, dobbel ekspertise prinsipper, retningslinjer og regler med eller uten kontekst Analysere flyt gjennom systemet overgangen mellom skjermbilder dialogsekvensiering Analysere hvert skjermbilde, dialog, melding osv. mot tommelfingerregler (heuristikker) Finner de fleste og viktigste feil med 5-10 eksperter

21 MMI-forelesninger Overordnet bilde av mennesker (aktører), oppgaver, informasjon og systemer (verktøy) Brukskvalitet Iterativ design og Usability Engineering Evaluering Oppgaveanalyse og modellering Scenariobygging Designteknikker

22 Oppgaveanalyse Kjært navn har mange betydninger trekke ut og representere brukeroppgaver forutsi problemer og evaluere mot brukbarhet og funksjonelle krav forutsi ytelse og måle kompleksitet måle læring og overføring av erfaringer Utgangspunkt i ergonomi, psykologi og SU Oppgave: målrettet handling på mange nivåer prosess, aktivitet oppgave aksjon, operasjon

23 Oppgaveanalyse forts. Begrepsavklaring: Goal/mål = tilstand som brukeren ønsker å oppnå Task/oppgave = set av handling som oppfattes som nødvendig for å nå et mål, gitt et sett av hjelpemidler Action/aksjon = atomisk handling uten problemløsning eller kontrollstruktur GOMS - Goals, Operations, Methods, Selection Oppgavestruktur hierarkisk dekomposisjon sekvensiering og valg

24 HTA plan 0: 1-2, deretter 2, 3, 4; 6 iht.krav; 5 hvert 15 min, etter større endringer, før utskrift og avslutning; 7 når ferdig 0brukeWP 1starte 2tekst 3 formattere 4 redigere 5lagre 6printe 7 avslutte plan 3: iht. krav plan 3: iht. krav aste hente paste tegn avsnitt dokument dekomponeres Overordnet dekomponering Detaljeringsnivå og granularitet Lovlig utførelser Kognitive prosesser

25 Vår TML: New Message container Method Make Folder from Mailbox mailbox 1.2 Split Mailbox Transfer to New... Method 2 Make Mailbox Drag Messages Make Folder folder Move Mailbox to Folder Set Folder name = name

26 Task modelling Often combines functions and concepts Two major formalisms: processes, dataflow and function networks hierarchical decomposition with sequence constraints Used both for understanding current work modes and practice specifying how work should be done Taskmodellingis work design! Easier to do in parallel with dialog and look & feel design

27 Workflow vs. task modeling A1 Write travel report Actors Tools returned from travel A1.1 Write report DETAILS REPORT A1.2 Provide details Simple Composite Role Roles Person Group Software Software suite Software product Suite product User App FINAL Secretary Abstract Concrete Abstract Concrete RE PORT OBJECTIONS dataflows A1.3 Sign report FINAL RE PORT Adm. A1.1 Write report User App Manager Make initial report Add details Handle objections U SER S UPP A PP Request details Receive details Fill in details Submit report Receive objections React Secretary Secretary Manager Manager

28 ruk av telefon... alternativer Bruke telefon sekvens overlappende Ringe ut Ta imot Samtale veksling nr? betinget Lagre nr. Summetone nr? Finne nr. nr flyt Taste nr. Notere Huske

29 TML example 1 Read Mailbox {} In conceptual model User client Mailboxes Out 1.1 Get new In task structure messages 1.2 Manage messages message Manage message Message A mailbox contains messages User performs Read using client The current set of mailboxes provides the task context Get new uses In mailbox and provides Manage with set of messages Read message Transfer message Manage implies acting on each individual message in the input set