INF5272 Informasjonarkitektur og innholdsadministrasjon Brukbarhetsanalyse, heuristisk evaluering Gisle Hannemyr Metodologi vs. metode Metode: «strategy of inquiry» dvs. framgangsmåter, oppskrifter, teknikker. Metodologi: «a theory and analysis of how research should proceed» dvs. en kritisk analyse av antagelser, prinsipper og prosedyrer knyttet opp mot datainnsamling studier av meodene, og ikke metodene selv. INF3272/5272 Side #2 1
Hvorfor er bruksaspektene viktige? 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 poor usability consequences until after they had paid for a physical product. But] users experience the usability of a site before they are committed to using it and before they have spent any money on potential purchases. Very clear why usability is more important for web design. Jakob Nielsen (2000, p. 9-11) INF3272/5272 Side #3 Hvorfor evaluere brukbarhet? En evaluering vil hjelpe oss å designe nettsteder med bedre interaksjon og bedre funksjonalitet. Evaluering kan støtte opp under planlegging, brukermedvirkning og en sosial utviklingsprosess Spørsmål: Kan det å delta i en slik undersøkelse også påvirke brukernes opplevelse av nettstedet? Positivt? Negativt? På andre måter? INF3272/5272 Side #4 2
Usability vs. usefulness Nytte (Usefulness) i kontekst: feltstudier, oppgaveanalyse, thinking aloud Brukbarhet (Usability), eksperimentelt i lab eller ved ekspertvurderinger INF3272/5272 Side #5 Usefulness vs. really useful Really useful «Total» analyse: samfunn organisasjon behov, med mer. Nytte (Usefulness) I kontekst: Feltstudier Oppgaveanalyse thinking aloud Brukbarhet (Usability), eksperimentelt i lab eller ved ekspertvurderinger INF3272/5272 Side #6 3
Evalueringsteknikker (oversikt) Brukbarhetsstudier: Studier gjort i Usability lab. «Review» (deriblant Heuristisk evaluering). Kognitive studier: «Thinking aloud» (Jørgensen 1989). «Contextual design» (Beyer and Holtzblatt 1998). Mange andre former for feltobservasjon av bruk og brukere. Supplerende teknikker: «Survey». «Focus group» (Nielsen 1997) Kvalitatativ log- og dokumentasjonsanalyse. Bruk av programvare for analyse. INF3272/5272 Side #7 Supplerende teknikker for datainnsamling «Focus group»: Samling (workshop) med seks til ni brukere for diskusjon av egenskaper og funksjoner. Kan brukes på idéstadiet, ved testing av prototyper, og ved evaluering av ferdig design. Kan brukes til å få innspill på lang tids bruk, noe som er dyrt å gjøre ved feltobservasjon. «Survey»: Spørreskjema med åpne svaralternativer. Intervju (strukturert, semistrukturert, åpent). Kvalitatativ log- og dokumentasjonsanalyse: Studere arkiver over ytringer (diskusjonsgrupper, etc.). Analyse av brukerdagbøker. Bruk av div. programvare for analyse: Validation suites (W3C HTML/CSS-validering). Analyse av web- og andre logger, div. numeriske data. Programvare for struktur- og lenkeråteanalyse, etc. INF3272/5272 Side #8 4
Brukbarhets-studier Fellesbetegnelse på metoder der man studerer eller analyserer egenskaper ved bruk i en ikke-naturlig brukssituasjon (i motsetning til feltstudier). Omfatter bl.a.: Usability lab (observasjon av bruk og brukere) «Review» (ekspertvurderinger) eksperter kommenterer løsningen fritt heuristisk evaluering (ekspertevaluering basert på retningslinjer) (Nielsen 1994a, 1994b). cognitive walkthrough (eksperter går gjennom oppgaver og stiller spørsmål ved hvert steg) (Wharton et al 1994) INF3272/5272 Side #9 Usability-lab Innhenting av kvantitative målinger «usability metrics» samt registrering av kvalitative data (ofte i form av video) Gjøres i kontrollerte omgivelser, gjerne i form av kontrollerte eksperimenter. Som regel i et eget laboratorium konstruert for formålet - en såkalt «Usability Lab». INF3272/5272 Side #10 5
Eksempel på Usability Lab - Microsoft INF3272/5272 Side #11 Kvantitative data (usability metrics) som typisk måles i en usability-lab suksess-rate (om bruker i det hele tatt klarer å løse en oppgave) tiden det tar brukeren å løse en oppgave tar hyppigheten av feil hvor lang tid det tar å lære seg å løse oppgaver vha. applikasjonen brukerens subjektive opplevelse (kvalitativt) fleksibilitet mulighet til å ta opp i seg endringer i utførelsen av oppgaven (kvalitativt) - J. Nielsen (2001), Usability Metrics: http://www.useit.com/alertbox/20010121.html INF3272/5272 Side #12 6
Usability metrics - fordeler Gir tellbare resultater, sammenlignbare med tidligere tester, gjør det mulig å måle forbedring. Bidrar til iterativ systemutvikling. Kan raskt avsløre «åpenbare» feil. INF3272/5272 Side #13 Mer om bruk av usability-lab I all hovedsak er funn fra usability-lab basert på observasjon og kvalitativ analyse. Usability-lab fungerer (i de aller fleste tilfeller) som et redskap for å detektere og diagnostisere potensielle problemområder med et nettsted eller med et interaksjonsdesign. I praksis kjører man sjelden mer enn 8 testpersoner som tilhører målgruppa (men som regel for dyrt med så mange testpersoner at de kan sies å være representative for målgruppa). INF3272/5272 Side #14 7
Katalog over metoder Usability testing Expert-based testing INF3272/5272 Side #15 Heuristisk evaluering (1) Heuristisk evaluering gjøres av en liten gruppe evaluatorer (cost/benefit considerations indicates that 3-5 is suitable). Heuristic evaluation is carried out by experts (domain experts or usability experts), not users. 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). Kort intro i Rosenfeld, Morville & Arango (2015, p. 324f). INF3272/5272 Side #16 8
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. INF3272/5272 Side #17 Framgangsmåte: Evalutorene 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. INF3272/5272 Side #18 9
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). INF3272/5272 Side #19 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. (Nielsen 1994b) INF3272/5272 Side #20 10
Kost/nytte (1) (Nielsen 1994b) INF3272/5272 Side #21 Kost/nytte (2) (Nielsen 1994b) 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. INF3272/5272 Side #22 11
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. INF3272/5272 Side #23 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.) INF3272/5272 Side #24 12
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. INF3272/5272 Side #25 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, Web Review, Oct., an adaption to better suit web site evaluation of Nielsen (1994a). INF3272/5272 Side #26 13
Ben Shneiderman (2009): 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. Cater to universal usability. There are many types of users. Novice vs. expert difference, age, and disabilities requires the designer to make the interface flexible and adaptable. 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. INF3272/5272 Side #27 Ben Shneiderman (2009): Eight golden rules of interface design 5. Prevent errors. 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). INF3272/5272 Side #28 14
Brukbarhet og sosialitet Støtt endring, vekst og videre utvikling Design med tanke på brukbarhet Planlegg med tanke på sosialitet Kartlegg hvilke behov nettsamfunnet har Fra: Preece, side 209 INF3272/5272 Side #29 Forslag til 8 heuristikker for sosialisering: Jenny Preece 1. Hvorfor skal jeg bli med i dette samfunnet? 2. Hvordan melder jeg meg inn/ut? 3. Hva er reglene til samfunnet? 4. Hvordan kommer jeg i gang med å lese/skrive meldinger? 5. Kan jeg gjøre det jeg vil på en enkel måte? 6. Er samfunnet trygt? 7. Kan jeg uttrykke meg slik jeg ønsker? 8. Hvorfor skulle jeg ønske å komme tilbake hit? Jenny Preece (2000) Online Communities. Designing Usability, Supporting Sociability, Wiley, s. 291-292 INF3272/5272 Side #30 15
Forslag til 9 heuristikker for sosialisering: Amy Jo Kim 1. Er det lett å finne frem til å forstå nettstedets formål? 2. Tilbyr nettstedet fleksible samlingssteder? 3. Finnes det meningsfylte dynamiske, medlemsprofiler? 4. Tilbyr nettstedet mange ulike roller? 5. Har nettstedet et program for verter og moderatorer? 6. Defineres det grenser/retningslinjer/nettvett? 7. Tilbys sykliske hendelser? 8. Betjener nettstedet seg av ritualer? 9. Finnes subgrupper som kan gi intimitet og tilhørighet? Amy Ko Kim (2000) Community-Building on the Web, Secret Strategies for Successful Online Communities, Peachpit Press. INF3272/5272 Side #31 16