Brukbarhetsstudieog oppgaveanlyse

Brukbarhetsstudieog oppgaveanlyse Analyse av digitale medier Gisle Hannemyr Ifi, vårsemesteret 2005 Motivasjon: Hvorfor er analyse av bruk viktig? Usability rules the Web. Simply stated, if the consumer can t find the product, then he or she will not buy it. The web is the ultimate customer-empowering environment. He or she who clicks the mouse gets to decide everything. It is so easy to go elsewhere; all the competitors in the world are but a mouseclick away. Usability used to be a secondary consideration in the computer industry because customers were not faced with the usability consequences until after they had paid for the product. But users experience a web site s usability from the very first moment they consider doing business with a company. Hence, usability has assumed a much greater importance in the Internet economy than it has in the past. Jakob Nielsen DIG 3810 Side #2 1

Usability vs. usefulness Nytte (Usefulness), i kontekst - feltstudier Brukbarhet (Usability), eksperimentelt i lab eller ved ekspertvurderinger DIG 3810 Side #3 Usefulness vs. really useful «Total» analyse: samfunn organisasjon behov, mm. Feltstudier, oppgaveanalyse, thinking aloud DIG 3810 Side #4 2

Kvantitative og kvalitative metoder (1) Kvantiative metoder Betrakter verden som noe som kan måles, veies og telles. Kvalitative metoder Betrakter verden som noe som primært blir definert gjennom opplevelser og sanseinntrykk. Begge tilnærmingene har tilhengere og motstandere. I dette kurset går vi ikke inn på denne debatten, men antar en eklektisk holdning til metodevalg. DIG 3810 Side #5 Kvantitative og kvalitative metoder (2) Kvalitative data Kvantitative data Objektiv Subjektiv Etnografiske data, intervjuer, observasjoner og artifakter som tolkes. Oppgaveanalyse Spørreskjemaer Usability metrics, analyse, av logger,laboratoriemålinger. DIG 3810 Side #6 3

Analyseteknikker (oversikt) Usability-studier: Usability lab, eksperimenter «Review» Feltobservasjon: Oppgaveanalyse «Thinking aloud» Andre former for observasjon Supplerende teknikker: (vil ikke bli drøftet videre her) «Survey» Kvalitatativ log- og dokumentasjonsanalyse Programvare for analyse DIG 3810 Side #7 Supplerende teknikker for datainnsamling «Survey»: Spørreskjema Intervju (strukturert, semistrukturert, åpent, fokusgruppe) Kvalitatativ log- og dokumentasjonsanalyse: Se på arkiver (diskusjonsgrupper, etc.) Analyse av brukerdagbøker Bruk av div. programvare for analyse: Validation suites Analyse av web- og andre logger, div. numeriske data Programvare for struktur- og lenkeråteanalyse, etc. DIG 3810 Side #8 4

Usability-studier Fellesbetegnelse på metoder der man studerer eller analyserer egenskaper ved bruk i en ikkenaturlig brukssituasjon (jf. feltstudier). Omfatter bl.a.: Usability lab (eksperimentelt) «Review» (ekpertvurderinger) o eksperter kommenterer løsningen fritt o heuristisk evaluering (ekspertevaluering basert på retningslinjer) DIG 3810 Side #9 Usability-lab Innhenting av kvantitative målinger «usability metrics». Gjøres i kontrollerte omgivelser, i form av kontrollerte eksperimenter. Som regel i et eget laboratorium konstruert for formålet - en såkalt «Usability Lab». DIG 3810 Side #10 5

Eksempel på Usability Lab - Microsoft DIG 3810 Side #11 Hva måles i en usability-lab Primært: tiden en oppgave tar hyppigheten av feil brukerens subjektive opplevelse (kvalitativt) Andre mulige målinger: hvor lang tid det tar å lære seg å løse oppgaver vha. applikasjonen fleksibilitet mulighet til å ta opp i seg endringer i utførelsen av oppgaven DIG 3810 Side #12 6

Usability-lab - spørsmål Kompetansnivået for testpersonene: Innen oppgaven. Når det gjelder teknologi generelt og applikasjonen. Viktig med oppgavespesifikke krav. Motivasjon. Kontekst. Jakob Nielsen: «Generally, to improve design, insight is better than numbers» http://www.useit.com/alertbox/20010121.html DIG 3810 Side #13 Usability tester - fordeler Kan raskt avsløre «åpenbare» feil. Gir tellbare resultater, sammenlignbare med tidligere tester, gjør det mulig å måle forbedring. Bidrar til iterativ systemutvikling. DIG 3810 Side #14 7

Heuristisk evaluering (1) Heuristic evaluation involves having a small set of evaluators (cost/benefit conside-rations indicates that 3-5 is suitable) Each evaluator works independent of each other to examine the user interface and judge its compliance with recognized usability principles. Heuristic evaluation is performed by having each individual evaluator inspect the interface alone. Only after all evaluations have been completed are the evaluators allowed to communicate and have their findings aggregated (to stop evaluators from influencing each other). DIG 3810 Side #15 Heuristisk evaluering (2) During the evaluation session, the evaluator goes through the interface several times and inspects the various dialogue elements and compares them with a list of recognized usability principles (the heuristics). Often, one want to supply the evaluators with a typical usage scenario, listing the various steps a user would take to perform a sample set of realistic tasks. Such a scenario should be constructed on the basis of a task analysis of the actual users and their work in order to be as representative as possible of the eventual use of the system. DIG 3810 Side #16 8

Framgangsmåte: Evalutoreme må utforske grensesnittet hver for seg, uavhengig av hverandre. Gå gjennom grensesnittet flere ganger. Ofte lurt å få oversikt før man går ned i detaljer. Evaluatorene skal vurdere designelementer opp mot på forhånd fastlagte retningslinjer (heuristikken). Skriver ned problem med referanse til retningslinje. Må forklare hvorfor noe er et problem i forhold til heuristikken. Hvert problem listes separat. DIG 3810 Side #17 Varianter Kan bruke en observatør som noterer det evaluatoren finner. Observatøren kan bistå med hjelp og domenekunnskap. Gi evaluereren et scenario å vurdere ut fra. Felles møte etter evalueringen (evaluerer, observatør, designere). DIG 3810 Side #18 9

Flere evaluatorer er viktig Ulike evaluatorer finner ulike problemer. De problemene som det er vanskeligst å finne (mot venstre i figuren) finnes ofte av evaluatorer som ikke finner så mange andre problemer. DIG 3810 Side #19 Kost/nytte (1) DIG 3810 Side #20 10

Kost/nytte (2) Nielsen gir også et estimat som for lønnsomheten til metoden: Gitt at vi har n evaluatorer og at å evalueringen koster $4000+$600 n (i faste og variable kostnader), og vi sparer $ 15000 for hvert problem vi finner. Topppunktet på kurven angir da optimal lønnsomhet, og ligger altså mellom 3 og 5 evaluatorer. DIG 3810 Side #21 Heuristisk evaluering: Særlige kjennetegn Vurdere grensesnitt ved å referere til retningslinjer (heuristics). Egnet for å finne også mindre problemer som man ikke finner ved systematisk testing (regresjonstesting). Kan brukes på papirprototyper. Minst 3-5 evaluerere anbefales. Bruke flere evaluatorer for å finne flere problemer. Forskjellige evaluatorer finner forskjellige problemer. De som finner få problemer finner ofte andre problemer enn de evaluatorene som finner åpenbare problemer. DIG 3810 Side #22 11

Heuristisk evaluering Fordeler kan brukes tidlig (prototypestadiet) kan brukes for evaluere hele designet kostnadseffektiv metode Ulemper forutsetter at det er mulig å lage gode retningslinjer representativitetsproblematikk (bruksituasjon, etc.) DIG 3810 Side #23 Forslag til 10 heuristikker: Keith Instone (etter J. Nielsen) 1. Systemets status er synlig. Hvor er jeg? hvor kan jeg gå? 2. Samsvar mellom system og den virkelige verden. Bruk brukerens språk 3. Brukerkontroll og frihet. Sørg for at brukerene kan kommet ut av uønskede tilstander. 4. Konsistens og lojalitet til standarder 5. Forhindre feil i entry-felt for skjemaer, o.l. DIG 3810 Side #24 12

Forslag til 10 heuristikker: Keith Instone (etter J. Nielsen) 6. Sørg for gode navn og deskriptive lenker. 7. Fleksibilitet og effektiv bruk, shortcuts. 8. Estetikk og design, unngå irrelevans. 9. Hjelp brukere å ta seg inn ved feil. En feilmelding bør tilby en løsning. 10. Hjelp og dokumentasjon integrert i nettstedet. Keith Instone (1997) Site Usability Heuristics for the Web, WebReview, Oct. DIG 3810 Side #25 Ben Shneiderman: Eight golden rules of interface design 1. Strive for consistency. It is important to make sure that the interface is consistent. Examples of this are making sure that labeling is consistent, terminology is similar, and layout follow a certain pattern 2. Enable frequent users to use shortcuts. When users begin to use the software more, they want to be able to reduce the amount of time it takes to interact with the program. 3. Offer informative feedback. It is important that feedback (i.e. errors, input requests) is informative. Every interaction the user has with the computer should result in an informative response. 4. Design dialogs to yield closure. Sequences of actions should be organized into a beginning, middle and end. It should be obvious to the user when a sequence is closed. DIG 3810 Side #26 13

Ben Shneiderman: Eight golden rules of interface design 5. Offer error prevention and simple error handling. Avoid opportunities for the user to cause a critical error. Using pull down menus instead of free form input limits the user s options. 6. Permit easy reversal of actions. All actions that can be reversible, should be. This allows the user to undo something that might have been a mistake or was not appealing to them. 7. Support internal locus of control. Users want to feel in control of the software. Don t surprise the user. If the user does not feel in control, they will feel anxiety and dissatisfaction 8. Reduce short-term memory load. Human short-term memory is not perfect (rule of thumb: humans can remember 7 +/- 2 items). DIG 3810 Side #27 Mori: De 10 største irritasjonsmomentene på web 1. Langsom nedlasting 2. Uforståelige hjelpefunksjoner 3. Krav om å registrere altfor detaljerte personlig opplysninger 4. Mangel på søkefunksjoner 5. Søk gir ikke relevante søkeresultater 6. Dårlig organisering av nettstedet 7. Rotete sideutlegg 8. Må scrolle ned på siden for å finne informasjon man trenger 9. Reklame 10. Pop-ups Fra Moris (www.mori.com) undersøkelse for Abbey National i februar 2002 av de største irritasjonsmomentene på web. DIG 3810 Side #28 14

Handikappede og webbruk Fargeblind webbutikk-kunde Journalist med musesyke Døv student Blind kontorpersonal Elev med dysleksi Pensjonist som ordne med innskudd Døvblind tenåring som søker underholdning DIG 3810 Side #29 WAI: Web Accessibility Initiative Jobber med tilgjengelighetsproblematikk Hovedaktiviteter Protocols and Formats Working Group Web Content Accessibility Guidelines Working Group Authoring Tool Accessibility Guidelines Working Group User Agent Accessibility Guidelines Working Group The Evaluation and Repair Tools Working Group Andre grupper som arbeider med dette: WAI Interest Group Education and Outreach Working Group (WAI Coordination Group) DIG 3810 Side #30 15

Web Content Accessibility Guidelines 1.0: Hovedpunkter 1. Alternativ til lyd & bilde 2. Ikke krev farger 3. Riktig bruk av markup og stylesheets 4. Støtt naturlig språk 5. Transformerbare tabeller 6. Ikke belag deg på ny teknologi 7. La bruker styre tidssensitive elementer 8. Sørg for at «embedded objects» (applet) har tilgjengelig GUI 9. Design for «device independence» 10. Gi løsning for eldre nettlesere og tekniske hjelpemidler 11. Bruk W3C teknologier og retningslinjer 12. Tilby kontekst og orienteringsinformasjon 13. Tydelige navigasjonsmekanismer 14. Sørg for at dokumenter er klare og enkle DIG 3810 Side #31 Utdrag fra Web Content Accessibility Guidelines 1.0 (nå finnes ver. 2.0 WD) (Retningslinjene har tre prioritetsnivåer som tilsvarer MÅ, SKAL, BØR.) 1.1 Provide a text equivalent for every non- text element (e. g., via "alt", "longdesc", or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e. g., animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand- alone audio files, audio tracks of video, and video. 2.1 Ensure that all information conveyed with color is also available without color, for example from context or markup. 4.1 Clearly identify changes in the natural language of a document's text and any text equivalents (e. g., captions). DIG 3810 Side #32 16

Utdrag fra sjekkpunkter for Web Content Accessibility Guidelines 1.0 6.1 Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document. 7.1 Until user agents allow users to control flickering, avoid causing the screen to flicker. 14.1 Use the clearest and simplest language appropriate for a site's content. 1.3 Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation. 1.4 For any time- based multimedia presentation (e. g., a movie or animation), synchronize equivalent alternatives (e. g., captions or auditory descriptions of the visual track) with the presentation. And if all else fails: 11.4 If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page. DIG 3810 Side #33 Verktøy http://www.w3.org/wai/er/existingtools.html Eksempel: Bobby Developed by CAST, Bobby helps authors determine if their sites are accessible. It does this through automatic checks as well as manual checks. It also analyzes Web pages for compatibility with various browsers. You may either download Bobby and run it locally, or use it through a Web interface on CAST's site. The downloadable version is written in Java and takes advantage of the accessibility support in Java. DIG 3810 Side #34 17

Oppsummering av usability-analyser Fordeler: usability-analyser er viktige for å forstå hvordan systemene fungerer i bruk kan bidra til iterativ systemutvikling kostbare og enkle feil kan lukes bort tidlig før prototypestadiet Ulemper: blir gjerne «anti-innovativt» konsentrasjon om detaljer på bekostning av helheten for mye vekt på styring av brukeren, særlig problematisk når vi arbeider med web-usability? DIG 3810 Side #35 Feltobservasjon Innebærer å studere (betrakte) brukere i aksjon i virkelige brukssituasjoner i brukernes vanlige omgivelser. Metoder: oppgaveanalyse (task analysis) passiv eller deltagende observasjon contextual enquiry (Karen Holtzblatt, Hugh Beyer) «thinking aloud» protokoller DIG 3810 Side #36 18

Oppgaveanalyse: task analysis Oppgaveanalyse er å studere hvordan folk utfører oppgaver ved hjelp av systemer som allerede eksisterer. Det eksisterende systemet trenger ikke være IKT-basert. Kan brukes til: Design av nye systemer Utforming av brukermanualer og lærerutiner DIG 3810 Side #37 Oppgaveanalyse (jf. Preece et al, 2002) Tilnærminger HTA : Hierarchical Task Analysis GOMS : Goals, Operations, Methods, Selection rules o Goals: Tilstanden brukeren vil oppnå o Operators: Kognituve prosesser og fysiske handlinger o Methods: Læring o Selection rules: Valg mellom alternative handlinger DIG 3810 Side #38 19

Datainnsamling For å kunne gjøre oppgaveanalyse må vi ha data om oppgavene vi analyserer. Typiske data kommer fra: Eksistende dokumentasjon Observasjon Intervjuer DIG 3810 Side #39 Oppgave-hierarkier (HTA) Oppgaver kan brytes ned i deloppgaver Noen oppgaver kan brytes ned i en klart definert sekvens av deloppgaver. Andre oppgaver kan løses på mange ulike måter, og det er ikke mulig å derfinere et entydig sett med deloppgaver. DIG 3810 Side #40 20

Oppgaveanalyse: Vanligste tilnærming (HTA) Nedbryting av en oppgave i dens enkeltdeler, i forhold til et mål: mål Bestille billett oppgaver betale handlinger oppgi kortnr. oppgi antall godkjenn beløp DIG 3810 Side #41 Nettsamfunn: Oppgaver som skal støttes av designet: (eksempler) Høynivå-oppgaver: Utveksle informasjon (kringkasting, spørsmål/svar-utveklslinger) Gi støtte og empati (utveksling av følelser verbalt eller ikke-verbalt) Småprat og sosialisering (interaktiv utveksling av korte meldinger) Diskusjon av ideer (utveksling av essay, arkivfunksjoner) Oppgaver på lavere nivåer: Meldingsredigering Kringkasting Asynkon, bi- og multilateral meldingsutveksling Arkivsøk Personlige annotasjoner DIG 3810 Side #42 21

Oppgaveanalyse - fordeler En verktøykasse av forskjellige teknikker for analyse, i et velutprøvd felt. Gir et analytisk hjelpemiddel, på et område uten så mange alternativer. Kan fungerer bra som kvalitetssikring, hindrer «blundere». Kan brukes før prototypestadiet (gitt at det finnes et eller annet system (f.eks. manuelle rutiner) å studere) DIG 3810 Side #43 Oppgaveanalyse - problemer Kan sementere eksisterende «gale», det vil si dysfunksjonelle rutiner. Kan snevre inn området som undersøkes ved at brukeren styres for mye. Kan gi et for snevert perspektiv på oppgaveløsning «mikrofokus». DIG 3810 Side #44 22

Thinking aloud Dette er en veldig enkel teknikk som kommer fra kognitiv psykologi der man prøver å «kikke inn i hodet til folk», eksempelvis for å forstå problemløsning. Mer «åpen» enn de tidligere omtalte metodene. Foregår primært på brukerens premisser. DIG 3810 Side #45 Grunnprinsipper Brukeren skal «tenke høyt» av seg selv mens han bruker systemet. Brukeren skal spontant og kontinuerlig ytre tanker og fraser. Dette registreres vha notater, video, båndopptager, systemlogging (protokoller)... Vanlig å etablere et scenario, med en oppgave. Oppvarming, lurt å starte med å venne brukeren til å tenke høyt. Brukeren skal fokusere på oppgaven ikke høyttenkningen. Lurt å gjøre en eller flere pilottester for å undersøke om opplegget fungerer. DIG 3810 Side #46 23

Observatøren skal: Minne brukeren om å tenke høyt ved taushet. Unngå å gripe inn for tidlig ved problemer. Ikke etablere en dialog med brukeren. Brukeren skal ikke forklare eller beskrive sine tanker, men tenke høyt! Kan være en ide å sette seg bakenfor brukeren. «Bare fortsett med å snakke» er bedre enn: «Hva tenker du?». DIG 3810 Side #47 Variasjoner over «thinking aloud» Supperende metoder: uformelt intervju rett etter forsøket. la brukeren kommentere et video-opptak fra sesjonen (retrospektiv testing). Varianter: Codiscovery learning: la to brukere teste systemet samtidig (også kalt «constructive interaction») Coaching: brukeren får stille spørsmål til en ekspert (kan brukes for å få frem den mentale modellen til nybegynner/ekspert) En kollega/ekspert forklarer hva en bruker gjør når han bruker systemet («Shadowing») Teach aloud: forklar bruken av systemet for en inaktiv partner Aktiv stilling av spørsmål («question-asking protocol») Fjernundersøkelse vha. teknologi som lar deg se skjermbildet til brukeren DIG 3810 Side #48 24

Videre utvikling av TA Passiv eller deltagende observasjon Contextual enquiry (Karen Holtzblatt, Hugh Beyer) DIG 3810 Side #49 Oppsummering Fordeler: lave infrastrukturkostnader (ingen lab) identifiserer også opphavet til misforståelser kan utføres i virkelige brukssituasjoner Ulemper: høyttenkning er unaturlig krever at det finnes en fungerende prototype DIG 3810 Side #50 25

Avslutningsvis: Kreativ bruk av teknikker er lov! Bruk de teknikkene som her er beskrevet som utgangspunkt for eget arbeide, ikke som oppskrifter. Tilpass eksisterende teknikker. Teknikker kan kombineres (for eksempel thinking aloud i en usabilty-lab-setting) Lag dine egne framgangsmåter. DIG 3810 Side #51 Forslag til videre lesning Hugh Beyer og Karen Holtzblatt (1998) Contextual Design, Morgan Kaufman Publishers, Inc. K. A. Ericsson og H. A. Simon (1993) Protocol Analysis, MIT Press A. H. Jørgensen (1989) Using the Thinking-Aloud Method in Systems Development, i G. Salvendy og M. J. Smith (red.) Designing and Using Human-Computer Interfaces and Knowledge Based Systems, Elsevier Science Publishers, s. 743-750. Jakob Nielsen (1993) Usability Engineering, AP Professional. Jenny Preece et al. (2002). Interaction design: Beyond human-computer interaction, J. Wiley & Sons. DIG 3810 Side #52 26