Brukbarhetstesting En introduksjon Praksis... Fremgangsmåte Trondheim, 2001 http://www.design..ntnu.no/
ISO 9241-210: User-centred design
Fasene i bruker-sentrert design (4) Identifisere behov for brukersenteret design! Evaluere design mot krav Evaluere design mot krav! ISO 13407 Forstå og spesifisere brukssammenheng! Systemet tilfredstiller bruker og organisasjons krav! Utvikle designløsninger! Spesifisere bruker og organisasjons krav! Teknikker for å evaluere designløsninger:!brukbarhetstesting.!fokusgrupper for feedback på løsning.!felt-tester og logging av bruk Teknikker for å formidle resultat fra evaluering:!testrapport fra brukbarhetstest (ISO/CIF)!Oppsummering av feedback fra fokusgruppe.!analyser av felt-tester og loggdata.
Definisjon av Usability! Brukskvalitet er... the effectiveness, efficiency, and satisfaction with which specified users achieve specified goals in particular environments (ISO 9241-11)! Anvendbarhet, Effektivitet og Tilfredsstillelse! for bestemte brukere! med bestemte mål! i bestemte omgivelser
Hvordan måler man et produkts brukskvalitet! Eksempel: Spiseredskaper.! Brukskvalitet er anvendbarhet, effektivitet og tilfredsstillelse...
...for bestemte brukere med bestemte mål i bestemte omgivelser.
En usability matrise OK +/- X +/- OK X X +/- OK
Brukskvalitet vs. andre egenskaper!!! Brukskvalitet er en kontekst-avhengig egenskap ved et produkt. Det er bare meningsfylt å måle brukskvalitet når man kan svare på:! Hvem er brukerne av produktet?! Hva ønsker de å bruke det til?! Hvor, og i hvilken sammenheng skal det brukes? Eksempler på det motsatte (kontekst-uavhengige egenskaper):! Vekt, Størrelse, Farge, Prosessorhastighet.! Disse egenskapene er de samme på mandag og tirsdag, for Ole og for Kari, på kontoret og på gaten.
Konsekvenser for evaluering! Forutsetninger for evaluering av brukskvalitet:! Hvem er brukerne av produktet?! Sykehuset: Krever tilgang til faktiske brukere: leger, sykepleiere, pasienter, administratorer,,! Hva ønsker de å bruke det til?! Sykehuset: Krever detaljert kartlegging av arbeidspraksis og informasjonsflyt i helsevesenet.! Hvor, og i hvilken sammenheng skal det brukes?! Sykehuset: Krever kunnskap om fysiske omgivelser, og mulighet til å teste på sykehus eller simulere disse i et laboratorium.
Hva ønsker man å måle i en test?! Anvendbarhet ( Effectiveness )! I hvilken grad lar oppgavene seg utføre med produktet?! Dekker systemet de relevante funskjoner, og får brukerne til å bruke de?! Effektivitet ( Efficiency )! Hvor effektivt lar oppgavene seg utføre?! Krever kvantitative mål på hvor mye tid som går med til data trouble vs. tid til faktisk oppgave.! Subjektiv tilfredstillelse ( Satisfaction )! Den opplevde brukskvalitet.! Krever tester, intervjuer, feltstudier, spørreskjemaer etc. for å fastslå den enkelte brukers opplevelse av systemet. Viktig for aksept.
Brukbarhetstester: formativ vs. summativ! Formativ:! Evaluering med den hensikt å gi tilbakemelding for å forbedre et produkt.! Fokus på hvilke feil brukerne oppdager og hvordan dette kan meldes tilbake til utviklerne.! Summativ:! Evaluering med den hensikt å godkjenne eller måle brukskvaliteten på et produkt.! Fokus på målbare kriterier som oppgavegjennomføring, feilrate, tidsbruk og spørreskjema som subjektiv tilfredstillelse.
Brukbarhetslaben ved NSEP (Norsk senter for elektronisk pasientjournal)!!!!! Lab for testing og design av helse-it NFR-finansiert prosjekt ved IDI Totalramme NFR/: 1.5 Mill. til utstyr. Egeninnsats : 50% lab. ingeniør i perioden. Prosjektsansvarlig: F.am. Dag Svanæs, IDI.
Brukere av laben! s vitenskapelig ansatte og stipendiater:! Utvikling og brukbarhetstesting av eksperimentelle systemer.! Utvikling og evaluering av utviklingsmetoder.! St.Olav og resten av helse-norge:! Uttesting av nytt utstyr før og etter anskaffelse.! Industri og FoU:! Uttesting av produkter og prototyper.
Typisk konfigurasjon
Brukbarhetslab med konfigurerbare vegger
Laboratoriet i bruk Kameraer og mikrofoner i taket. Labområde Kontrollrom
Kontrollrom
Teknisk utrustning i laben Styrbare kameraer i taket Trådløse mikrofoner på brukerne Trådløst spion- kamera for brille Faste mikrofoner i rommet. Speiling av faste PCer og trådløse PDAer Speiling ved hjelp av KVM over IP
Takmonterte kameraer Styrbare fra kontrollrom
Datainnsamling takmonterte kameraer
Datainnsamling mobile enheter: speiling Speiling Video
Datainnsamling, mobile enheter
Analyseverktøy Noldus - The observer
Eye tracking (Tobii)
Heat maps
Arbeidsstegene i brukbarhetstesting: 1.! Utvikling av målsettinger og hypoteser for testen og utvikling av testplan (hvor, når osv.) 2.! Skaffe brukere gjennom tilfeldig eller stratifisert utvalg 3.! Forberede materiale og kontekst 4.! Pilot-test 5.! Velg forsøksleder 6.! Utføre testen (10 punkter) 7.! Omforming av data til funn og anbefalinger Trondheim, 2001 http://www.design..ntnu.no/
1.! Utvikling av målsettinger og hypoteser for testen og testplan! Hvem er kunde for brukbarhetstesten?! Hva er hensikten med testen?! Hva skal resultatene brukes til?! Gjør eksplisitt hvilke ressurser som trengs! Når skal testen gjennomføres?! Hvem er ansvarlig?! Fungerer som kommunikasjon mellom de som er involvert.
2. Skaffe brukere gjennom tilfeldig eller stratifisert utvalg.! Eksempel på brukerkarakteristikker:! Personlig historie:! Alder, kjønn, holdninger til typen av produkt, hendthet, læringsstil, holdning til teknologi! Utdanningshistorie:! Høyest oppnådde grad, Fag! Erfaring med IKT:! (hvor lenge, hvor ofte, hvilken type operativsystem)! Produkterfaring! Tid brukt på produktet, frekvens, hvilken type oppgaver, hvilken type (bruker de "ditt" produkt)?! Jobbhistorie! Nåtidig og tidligere jobb, ansvar for hva, hvor lenge i nåtidig stilling etc.
! Antall brukere avhenger av flere faktorer:! Hvor høy grad av objektivitet som er nødvendig! Ressurser man har til rådighet for å utføre testen! Tilgjengelighet av brukere! Varigheten av testen! Kompleksiteten av brukergrensesnittet! Normalt vil antallet for en brukbarhetstest ligge mellom 5 og 8! (Telenor Mobil bruker 8 fordi...)
3. Forberede materiale og kontekst! Forbered testen i detalj.! Hva skal testes (programvare, papirprototyp,,)?! I hvilken omgivelse skal den testes (kontor, simulert sykehus, kafe,,)?! Hvilke oppgaver skal brukerne løse?
Utvikle et scenario for testen!!!!!! Lag så realistiske og komplette scenarioer som mulig. Bruk gjerne case studier, oppgaveanalyser eller faktiske observasjoner for å få scenarioet så realistisk som mulig. Lag scenarioet slik at rekkefølgen på oppgaven tilsvarer det den ville gjort i virkeligheten. Match scenarioet i forhold til brukerne: Enkle scenarier til noviser, mer komplekse for eksperter. Unngå jargon Unngå å gi "hint" til oppgavens løsning, gjennom måten man presenterer oppgaven på. Unngå å bruke ord som tilsvarer navnet på den funksjonen du vil at de skal bruke Presenter oppgaven i målrettet form med et enkelt språk (presenter målet med oppgaven, ikke enkeltstegene)
! Sett opp brukbarhetslaboratoriet:
4. Velge forsøksleder! Hvem bør være forsøksleder?! Intern human factors - spesialist (akseptabel objektivitet, akseptabel kunnskap om produktet)! Marketing spesialister / teknikere (god kjennskap til produktet, men kan ha lav grad av objektivitet)! Ekstern konsulent (god objektivitet / profesjonalitet, kan ha lav kjennskap til produktet)
5. Pilot test! Å gjennomføre en pilottest er viktig for å oppdage svakheter ved metodikken og test-designet! Gir testteamet anledning til å øve seg
6. Utføre testen:! 10 retningslinjer
7. Omforming av data til funn og anbefalinger!!!!!! Identifiser feilhandlinger og problemer ved logging av sammenbrudd! "Real time" score-ing! Videoanalyser Forsøk å komme til bunns i hva problemene skyldes (de mer bakenforliggende problemene) Prioriter funnene (fordi funnene kan være interavhengige, bør man fokusere på de viktigste funnene først) Utvikle løsningsforslag Indiker hvor man trenger ytterligere forskning Produser rapport
Ti punkter om å utføre brukbarhetstesting 1.! Introduser deg selv 2.! Beskriv hensikten med testen 3.! Fortell deltakerene at de kan avbryte når de vil 4.! Beskriv utstyret i rommet og begrensningene til prototypen 5.! Lær bort hvordan man tenker høyt 6.! Forklar at du ikke kan tilby hjelp under testen 7.! Beskriv oppgaven og introduser produktet 8.! Spør om det er noe de lurer på og kjør testen 9.! Avslutt testen med å la brukeren uttale seg før du samler evnt. løse tråder 10.!Bruk resultatene Trondheim, 2001 http://www.design..ntnu.no/
1: Introduser deg selv! Fortell hvem du er og hvem de andre i teamet er! Handhils som vanlig! Hensikt - trygghet
2: Beskriv hensikten med testen! Fortell at Vi trenger hjelp med å teste ut et produkt i en tidlig fase av design! Vi trenger et friskt syn på dette slik at vi kan forbedre produktet! Vi tester produktet og ikke deg! Det er ikke deg og dine ferdigheter vi er interessert i men hvor brukbart produktet er! Hensikt - forståelse for våre forventninger og behov
3: Fortell deltakerne at de kan avbryte når de vil! Si at dersom brukeren av en eller annen grunn skulle føle ubehag ved å gjøre testen kan de avbryte testen uten at vi vil ha problemer med det! Full frivillighet og kontroll! Si at det ikke finnes skjulte motiver her. Det er ikke et intrikat psykologisk eksperiment hvor vi egentlig tester deg! Hensikt - Trygghet tillit og følelse av kontroll
4: Beskriv utstyret i rommet! Pek på alle dingser og forklar hva de brukes til! Også til som ikke inngår i testen men som bare står der! Hensikt - fokus på det testen skal handle om
5: Lær hvordan du tenker høyt! For å få et innblikk i de indre prosessene som ligger bak brukernes handlinger er det viktig at de verbaliserer det de tenker! Lær bort tenke-høyt-metoden ved å gjøre det selv og sammen med brukeren! Hensikt - få innsikt i brukerens strategier og mentale modeller
6: Forklar at du ikke kan tilby hjelp under testen! Forklar at du ikke kan svare på spørsmål underveis fordi vi ønsker brukerens mening! Men at det blir anledning til å spørre og diskutere etterpå! Be likevel om at de sier det de lurer på underveis slik at det blir lettere å huske det til etterpå! Forklar om prototypensbeskaffenhet og hvordan den avviker fra virkeligheten
7: Beskriv oppgaven og produktet! Beskriv de oppgavene du vil brukerene skal utføre! Legg en summarisk oppgaveliste ved siden av dem! Beskriv produktet/systemet! Pass på å ikke avsløre funksjonalietet eller operative begrep (objekter og relasjoner) som du ønsker feedback på
8: Spør om det er noe brukeren lurer på - kjør testen! La brukeren komme til orde før testen starter! Kjør testen og vær da bare observatør - reflekter brukerens spørsmål tilbake til dem! Det er viktig å ikke gripe inn når ting går galt, men la brukeren få bruke tid.! Ta detaljerte notater - bruk video om mulig
9: Avslutt testen og samle løse tråder! Avslutt testen når alle oppgaver er avsluttet eller tiden er oppbrukt! Svar på brukerens spørsmål! Diskuter ting dere fant interessant underveis! Be om en subjektiv vurdering og eventuelle forslag til redesign! La videoen gå!
! Ikke korriger problemer i produktet der og da! Hjelp brukeren bare som en siste utvei:! Når de er veldig "lost" eller veldig forvirret! Når oppgaven tydelig gjør brukeren ukomfortabel! Når brukeren er så frustrert at det er like før hun gir opp! Når det er en "missing link" i produktet! Under bugs eller krasj i systemet! Når du hjelper brukeren:! Ikke skyld på brukeren! Hjelp brukeren gradvis forbi problemet (det ligger mye verdifull informasjon i en slik situasjon)! Vær oppmerksom på at hjelpen også kan påvirke det som skjer senere i forsøket. Vær forsiktig!
! Under testen er det viktig å:! Gi brukeren en tidlig følelse av suksess (lette oppgaver)! Presenter en oppgave av gangen (reduserer mental belastning)! Hold en avslappet atmosfære i testrommet (server kaffe/ta pauser)! Unngå forstyrrelser; lukk døren og sett opp lapp. Slå av telefoner! Aldri hint til brukeren om at hun gjør feil eller jobber sakte! Minimer antall observatører i rommet (sett opp monitor i rommet ved siden av)! Ikke la overordnede observere brukerne! Hvis forsøkslederen får en følelse av at testsituasjonen er belastende for brukeren: Avslutt forsøket
! Observer testen upartisk, ikke la brukeren få en følelse av dine preferanser.! Vær oppmerksom på hvordan du sier ting og ditt eget kroppsspråk. Det skal svært lite til før brukerne aner hva du mener! Behandle hver enkelt bruker som et individ (ta pauser mellom brukerne)! Ikke redd brukerne når de sliter med et problem! Vær sikker på at brukerene er ferdig med oppgaven før du går videre (brukeren er ofte veldig usikker, selv om hun har utført den riktige responsen)! Interager med brukeren underveis for å sikre verbalisering
! Når du interagerer med brukeren:! Ikke vis at du er overasket (si for eksempel "hadde du forventet at det skulle skje?")! Fokuser på hva brukeren forventer når hun utfører en handling! Hold deg i bakgrunnen, og reflekter tilbake det brukeren har sagt. Hjelp brukeren med å uttrykke det de tenker! Bruk en passiv språkform! Hvis du avbryter brukeren, gjør diskusjonen kort. Spar lengre diskusjoner til etterpå! Vær oppmerksom på brukerens verbale og nonverbale responser. ("var det problematisk?", "Hva tenker du på nå?")! Vær hele tiden på jakt etter å forså rasjonalen bak brukerens handlinger. Hvis brukeren indikerer en annen designløsning: følg opp dette.
Noen punkter for gjennomføring av debreifingen! Begynn med å la brukeren få utrykke hva hun har på hjertet! Begynn diskusjonen på "høyt" nivå (generelle aspekter)! Beveg dere så mot mer konkrete aspekt! Gå tilbake til punkter du evt. noterte deg under seansen! Fokuser på å forstå problemene, ikke på å løse de! Etter at alle aspekter er diskutert, åpne for innspill fra de andre i labben! Hvis mulig, åpne for at brukeren kan komme tilbake for ytterligere informasjon eller innspill! Husk å fremdeles holde deg upartisk når dere diskuterer etterpå. Ikke si noe som gjør at brukeren føler hun må forsvare handlingene sine.
Etiske aspekt ved brukbarhetstesting! Selv om brukbarhetstesting ikke er farlig for forsøkspersonene, blir de likevel utsatt for et psykisk press, og det er derfor viktig før testen starter å:! Ha alt klart når brukeren kommer! Understrek at det er systemet som blir testet, ikke brukeren! Gjør oppmerksom på at produktet er nytt, og kan ha bugs! Informer om at brukeren kan trekke seg når som helst! Forklar hva som blir registrert under testen (introduser utstyr)! Forklar brukerne at resultatene er konfidensielle og hvordan de skal brukes! Vær sikker på at du har besvart brukerens spørsmål før testen
10: Bruk resultatene!! Etter at alle testene er gjort:! Analyser sammenbruddene! List opp og priorieter problemene! Finn årsakene til de viktigste problemene! Let etter alternative design løsninger! Husk - hensikten med testen er input til redesign! Hensikten med prototypen er å ha materiale å teste! Tester der resultatene ikke brukes er bortkastet tid! Protottyper som aldrig testes er bortkastet tid
Bruk av spørreskjema! I en del tilfeller kan det være lurt å la brukeren fylle ut et enkelt spørreskjema etter testen.! Det finnes flere standardiserte skjema, bl.a. SUS (System Usability Scale).! SUS gir et tall mellom 0 og 100 på opplevd brukervennlighet.
SUS (System Usability Scale)! 10 spørsmål på et A4 ark.! Enkel formel for å regne ut en samlet SUS score mellom 0 og 100.
Heidegger om objekter og verktøy!!!!! Når vi bruker et verktøy er det for oss gjennomsiktig i bruk. Verktøyet eksisterer som objekt, men er en del av det gitte ved situasjonen ( bakgrunnen ). Hvis verktøyet slutter å virke gjennom et sammenbrudd, blir det igjen et objekt i verden. Ved et sammenbrudd framstår verden på en ny måte i form av objekter, deres sammenheng og potensialer for bruk. Heidegger gjør den tyske endelsen zeug ( tøy ) om til et substantiv og snakker derfor om verktøy, kjøretøy, klestøy, fartøy, fyrtøy,,. D.v.s. alt som vi bruker for å oppnå noe.
Tolkning av sammenbrudd! Tre årsaker til sammenbrudd :! Manglende funksjonalitet.! Manglende kommunikasjon om funksjonalitet.! Feil målgruppe (kunnskapskrav, fysiologi++)! Kilder til innsikt:! Observasjon av bruk.! Intervju etterpå.! Egne erfaringer.
Noen oppsummerende poeng All testing er bedre enn ingen testing Prototyper skal lages i løpet av dager, ikke uker og måneder. Just enough prototyping Ikke kast bort tiden på å diskutere design spørsmål som kan testes Job iterativt: Design - Test - Design - Test - Design.. Trondheim, 2001 http://www.design..ntnu.no/
Eksempler på brukertester 1.! Vanlige systemer (skrivebordsarbeid) 2.! Flere skjermer samtidig 3.! Systemer med mange brukere samtidig 4.! Store kliniske systemer 5.! Kontekstsensitive systemer
Eksempel 1: Vanlige desktopsystemer (Digital video, HDTV-oppløsning)
ehelse: Kreftpasienter! 14 kreftpasienter og 14 i kontrollgruppe! Samme oppgave! Målte task completion Kilde: Hovedoppgave Anita Das, 2007
Resultat av test Gjennomførte alle oppgavene 16 14 12 10 8 6 4 10 2 0 4 Kreftpasienter Kontrollgruppe Kilde: Hovedoppgave Anita Das, 2007
Eksempel 2: Bruk av mobil og PC sammen
Eksempel 3: Systemer med mange brukere
Eksempel 4: Kliniske systemer
Scenarie for testing av mobil IT på sykehuset 1. Vaktskifte Kl. 07.30 Forrige sykepleier gir rapport til sykepleier (ca 5 min) 2. Previsitt Kl. 09.00: Sykepleier og lege. 2 stk. PC med Doculive. En til hver. 3 stk. kurvemapper.!informasjon. Gjøre seg kjent med pasientene hver for seg. (5-10 min.)!previsitt. 5 min. pr. pasient (totalt 15 min.) 3. Visitt_ Maks 15-20 min. 3 stk. pasienter. 4. Dokumentasjon / Medisinering (delvis parallelt). Lege dokumenterer på previsittrommet. Sykepleier administrerer medisiner (venter på papirkurven) Ca 10 min
Eksempel 5: Kontekstsensitive systemer
!"#$%&$'()*(#+++,+%(+'((%$-%)%.+(%/&0122+ 3%#)#$+45%$$'(6+7+8(%/%+9$'()%+ :$;'<'$+ =66)$'.>-+?@@A+
B$#"#"CD%+0()%$+."')>6+%()$>(6++
E+&$02%$"%."%$+!"#$%&!"'()'& FGH$+5%6+&'$%+.2'-+.0$I%+ $0()"+#6+.5%22%+D$>.+.H+J>-+ 5%6+>22%+-%66%+>65%(+ IK).%-.(0<<%$%"+<>/+L+ M%/%+%$+"CD>.2+&'(2+#6+ I#$.>2$>(6NF++ 0'%"$'1)"&2'%)"#)$34&& P*+QK).%-.(0<<%$+R%$(%.+?*+Q#$.>2$>(6..D$H2%"+&->$+I#$%(2-%"+ S*+T5%-D%"%2."%$+-%66%.+>((++ E*+!DK$.<H-+20/%.+<'2.><'-"+ *)'+)&,$-)"&./)& FM%/%+J'$+%(+J%-)>6+O(+ -K.(>(6+L+)%"+J'$+(%."%(+.#<+%"+.D>--N+ 3>-+<%6+.#<+%$+.H+->"%+ %$I'$>(6+DH+>("%$(%/+.H+ J'$+)%/%+J%-)>6+-%/NF+++
B$#"#"CD%+.#<+'$&%>).J%$2"KC+
U2#(%$+
U2#(%$+#6+I0(2.5#('->"%"+
RESULTATER
M%"+I0(2%$N++
V%.0-"'"+ W! XH-+I#$+?@@AY+P@*@@@+20()%$+&-%+(H))+'--%$%)%+ P*'060."+ W! Z@[+'J+.'-6%"+.25%$+DH+J>'+U("%$(%/.>)%(%+ W! 4$02%$.0DD#$"+(%."%(+->2+@+ W! Q-%$%+#(->(%+20()%$+#J%$+\@+H$+ W! E@[+'J+.'-6%"+.25%$+0"%(I#$+(#$<'-+2#("#$1)+]PZY@@^+ W! _#(J%$"%$>(6.$'"%+<%$+%((+)#&&%-"+.H+;KC+.#<+'()$%+.'<<%(->6(&'$%+.%-.2'D%$++
_0()%(%+%$+25%<D%I#$(KC)%+ W! FT%>N+`>-+&'$%+.>+<%6+P@@[+I#$(KC)+<%)+&H)%+ )%2(>(6%$a+D$>.+#6+"%2(>.2+-K.(>(6+)'+5%6+I#$+b+<>(*+.>)%(+#J%$IK$"%+<>(%+.2')%I#$.>2$>(6%$+1-+M%$%.+.%-.2'D+#J%$+(%/%"*+M%"+"#2+<%6+P@+<>(0/%$a+#6+5%6+.D'$"%+c'+E@[+,+.-H+)%(+NNNNF++ W! FT%>N+`>-+&'$%+.>+'"+5%6+'220$'"+&C/%"+I#$.>2$>(6+#6+)%"+ J'$+5#+0"$#->6+%(2%-+D$#.%..*+G%/.>)%(%+J'$+ 25%<D%#J%$.>2"->6%+#6+)%"+;%-%+"#2+2#$"+1)*+d6+5%6+.D'$%$+D%(6%$Y,^F+