21.01.2014 Views

Testmetodikk - NTNU

Testmetodikk - NTNU

Testmetodikk - NTNU

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

<strong>NTNU</strong><br />

Brukbarhetstesting<br />

En introduksjon…<br />

Fremgangsmåte…<br />

Praksis...<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


Hva er "brukbarhet"?<br />

<strong>NTNU</strong><br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


Hva er "brukbarhet"?<br />

<strong>NTNU</strong><br />

• Ifg. ISO 13407<br />

"…the<br />

effectiveness,<br />

efficiency and<br />

satisfaction with<br />

which specified<br />

users can achieve<br />

specified goals in<br />

particular<br />

environments…"<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


Brukbarhetstesting:<br />

<strong>NTNU</strong><br />

• Ifg. ISO13407: "…to ensure that the delivered product<br />

reaches a minimum required level of usability, to<br />

provide feedback during the design on the extent to<br />

which the objectives are being met, and to identify<br />

potential usability defects in the product".<br />

• European Usability Support Centers<br />

http://www.lboro.ac.uk/research/husat/eusc/<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


Mål for brukbarhetstestingen kan for<br />

eksempel være:<br />

<strong>NTNU</strong><br />

• Øke brukbarheten for et produkt<br />

• Å sette usabilitystandarder for kommende produkter<br />

(benchmarking)<br />

• Øke salget av et produkt samt øke sannsyneligheten av<br />

gjenkjøp av nye modeller<br />

• Å gi et konkurransefortrinn i markedet<br />

• Minimere risikoen før release av et produkt<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


Brukbarhetstesting er ikke alt...<br />

<strong>NTNU</strong><br />

• Nielsen (1993) plasserer usability slik i forhold til<br />

systemets totale akseptabilitet:<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


Brukbarhetslaboratoriet:<br />

<strong>NTNU</strong><br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


Ulike typer av brukbarhetstester<br />

<strong>NTNU</strong><br />

• Utforskende tester (kvalitativ)<br />

– Brukes på et tidlig stadium for å vurdere effektiviteten av<br />

tidlige modeller (designets "høyere" nivå)<br />

• Vurderingstester (kvalitativ og kvantitativ)<br />

– Den vanligste formen for brukbarhetstester. Gjennomføres<br />

tidlig eller midtveis i designprosessen.<br />

• Verifiseringstester (kvantitativ)<br />

– Objektiv sertifisering av produktets brukbarhet<br />

• Sammenlignende test (kvalitativ og/eller kvantitativ)<br />

– Brukes til å sammenlikne konsept, funksjoner eller produkt<br />

alle de andre tre fasene<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


Arbeidsstegene i brukbarhetstesting:<br />

<strong>NTNU</strong><br />

1. Uvikling av målsettinger og hypoteser for testen og<br />

utvikling av testplan (hvor, når osv.)<br />

2. Pilot-test<br />

3. Skaffe brukere gjennom tilfeldig eller stratifisert utvalg<br />

4. Forbrede materiale og kontekst<br />

5. Velge forsøksleder<br />

6. Utføre testen (10 punkter)<br />

7. Omforming av data til funn og anbefalinger<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


1. Uvikling av målsettinger og<br />

hypoteser for testen og testplan<br />

<strong>NTNU</strong><br />

• Gir en oppskrift på det som skal gjennomføres - sikrer<br />

at alt er klart til testing<br />

• Fungerer som kommunikasjon mellom ulike deler av<br />

designteamet<br />

• Gjør eksplisitt hvilke ressurser som trengs<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


<strong>NTNU</strong><br />

• Testplan - betraktninger<br />

– Between subjects: Hver forsøksperson går igjennom en<br />

betingelse (Vær oppmerksom på bias i utvalg og i gruppene)<br />

– Within subjects: Alle forsøkspersonene går igjennom alle<br />

betingelsene (Vær oppmerksom på treningseffekt)<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


<strong>NTNU</strong><br />

• Testplan - betraktninger<br />

– Definisjon av oppgaver:<br />

• Hvilke ting vil vi at bruker skal gjøre?<br />

• Hvor spesifikke kan vi bli uten å lære bruker riktig bruksmåte?<br />

(ofte er det best å formulere generelle oppgaver knyttet til<br />

brukerens aktivitet ikke til systemets funksjonalitet)<br />

– Definisjon av målebetingelser<br />

• Når/hvordan kan vi erklære en oppgave for<br />

fullført/sammenbrutt?<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


2. Pilot test<br />

<strong>NTNU</strong><br />

• Å gjennomføre en pilot - test er viktig for å oppdage<br />

bugs i produktet, men også for å finne svakheter ved<br />

metodikken og test-designet<br />

• Gir test teamet anledning til å øve seg<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


3. Skaffe brukere gjennom tilfeldig<br />

eller stratifisert utvalg.<br />

<strong>NTNU</strong><br />

• Eksempel på brukerkarakteristikker:<br />

– Personlig historie:<br />

• Alder, kjønn, holdninger til typen av produkt, ”hendthet”, læringsstil,<br />

holdning til teknologi<br />

– Utdanningshistorie:<br />

• Høyest oppnådde grad, Fag<br />

– Erfaring med IKT:<br />

• (hvor lenge, hvor ofte, hvilken type operativsystem)<br />

– Produkterfaring<br />

• Tid brukt på produktet, frekvens, hvilken type oppgaver, hvilken type<br />

(bruker de "ditt" produkt)?<br />

– Jobbhistorie<br />

• Nåtidig og tidligere jobb, ansvar for hva, hvor lenge i nåtidig stilling etc.<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


<strong>NTNU</strong><br />

• Antall brukere avhenger av flere faktorer:<br />

– Hvor høy grad av objektivitet som er nødvendig<br />

– Ressurser man har til rådighet for å utføre testen<br />

– Tilgjengelighet av brukere<br />

– Varigheten av testen<br />

– Kompleksiteten av brukergrensesnittet<br />

• Normalt vil antallet for en brukbarhetstest ligge<br />

mellom 5 og 8<br />

• (Telenor Mobil bruker 8 fordi...)<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


<strong>NTNU</strong><br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


4. Forberede materiale og kontekst<br />

<strong>NTNU</strong><br />

• Lag en mal for testen: Det er viktig at brukerne får all<br />

informasjon, samt at alle brukerne får den samme<br />

informasjonen.<br />

• Malen kan for eksempel inneholde:<br />

• Introduksjon (Hvem er vi, hva skal skje)<br />

• Forklar brukerne hvorfor de er her<br />

• Introduser utstyr og de som er med på testen<br />

• Forklar nøye hva som forventes av brukeren (thinking aloud)<br />

• Forklar at det er systemet som testes (ikke brukeren), at de kan<br />

trekke seg når som helst og at de kan spørre om ting når som<br />

helst<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


• Utvikle et scenario for testen<br />

<strong>NTNU</strong><br />

• Lag så realistiske og komplette scenarioer som mulig.<br />

Gjerne bruk case studier, oppgaveanalyser eller faktiske<br />

observasjoner for å få scenarioet så realistisk som mulig.<br />

• Lag scenarioet slik at rekkefølgen på oppgaven tilsvarer<br />

det den ville gjort i virkeligheten<br />

• Match scenarioet i forhold til brukerne: Enkle scenarier til<br />

noviser, mer komplekse for eksperter.<br />

• Unngå jargon<br />

• Unngå å gi "hint" til oppgavens løsning, gjennom måten<br />

man presenterer oppgaven på. Unngå å bruke ord som<br />

tilsvarer navnet på den funksjonen du vil at de skal bruke<br />

• Presenter oppgaven i målrettet form med et enkelt språk<br />

(presenter målet med oppgaven, ikke enkeltstegene)<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


• Sett opp brukbarhetslaboratoriet:<br />

<strong>NTNU</strong><br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


5. Velge forsøksleder<br />

• Hvem bør være forsøksleder?<br />

<strong>NTNU</strong><br />

• Intern human factors - spesialist (akseptabel objektivitet,<br />

akseptabel kunnskap om produktet)<br />

• Marketing spesialister / teknikere (god kjennskap til produktet,<br />

men kan ha lav grad av objektivitet)<br />

• Ekstern konsulent (god objektivitet / profesjonalitet, kan ha lav<br />

kjennskap til produktet)<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


6. Utføre testen:<br />

• 10 retningslinjer som vi kommer tilbake til<br />

<strong>NTNU</strong><br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


7. Omforming av data til funn og<br />

anbefalinger<br />

<strong>NTNU</strong><br />

• Identifiser feilhandlinger og problemer ved logging av<br />

sammenbrudd<br />

– "Real time" score-ing<br />

– Videoanalyser<br />

• Forsøk å komme til bunns i hva problemene skyldes (de mer<br />

bakenforliggende problemene)<br />

• Prioriter funnene (fordi funnene kan være interavhengige, bør<br />

man fokusere på de viktigste funnene først)<br />

• Utvikle løsningsforslag<br />

• Indiker hvor man trenger ytterligere forskning<br />

• Produser rapport<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


Ti punkter om å utføre<br />

brukbarhetstesting<br />

<strong>NTNU</strong><br />

1: Introduser deg selv<br />

2: Beskriv hensikten med testen<br />

3: Fortell deltakerene at de kan avbryte når de vil<br />

4: Beskriv utstyret i rommet og begrensningene til prototypen<br />

5: Lær bort hvordan man tenker høyt<br />

6: Forklar at du ikke kan tilby hjelp under testen<br />

7: Beskriv oppgaven og introduser produktet<br />

8: Spør om det er noe de lurer på og kjør testen<br />

9: Avslutt testen med å la brukeren uttale seg før du samler evnt. løse<br />

tråder<br />

10: Bruk resultatene<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


1: Introduser deg selv<br />

<strong>NTNU</strong><br />

• Fortell hvem du er og hvem de andre i teamet er<br />

• Handhils som vanlig<br />

• Hensikt - trygghet<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


2: Beskriv hensikten med testen<br />

<strong>NTNU</strong><br />

• Fortell at “Vi trenger hjelp med å teste ut et produkt i<br />

en tidlig fase av design”<br />

• “Vi trenger et friskt syn på dette slik at vi kan forbedre<br />

produktet”<br />

• “Vi tester produktet og ikke deg”<br />

• “Det er ikke deg og dine ferdigheter vi er interessert i<br />

men hvor brukbart produktet er”<br />

• Hensikt - forståelse for våre forventninger og behov<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


3: Fortell deltakerne at de kan avbryte<br />

når de vil<br />

<strong>NTNU</strong><br />

• Si at dersom brukeren av en eller annen grunn skulle<br />

føle ubehag ved å gjøre testen kan de avbryte testen<br />

uten at vi vil ha problemer med det<br />

• Full frivillighet og kontroll<br />

• Si at det ikke finnes skjulte motiver her. Det er ikke et<br />

intrikat psykologisk eksperiment hvor vi egentlig<br />

tester deg<br />

• Hensikt - Trygghet tillit og følelse av kontroll<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


4: Beskriv utstyret i rommet<br />

<strong>NTNU</strong><br />

• Pek på alle dingser og forklar hva de brukes til<br />

• Også til som ikke inngår i testen men som bare står der<br />

• Hensikt - fokus på det testen skal handle om<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


5: Lær hvordan du tenker høyt<br />

<strong>NTNU</strong><br />

• For å få et innblikk i de indre prosessene som ligger<br />

bak brukernes handlinger er det viktig at de<br />

verbaliserer det de tenker<br />

• Lær bort tenke-høyt-metoden ved å gjøre det selv og<br />

sammen med brukeren<br />

• Hensikt - få innsikt i brukerens strategier og mentale<br />

modeller<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


6: Forklar at du ikke kan tilby hjelp<br />

under testen<br />

<strong>NTNU</strong><br />

• Forklar at du ikke kan svare på spørsmål underveis<br />

fordi vi ønsker brukerens mening<br />

• Men at det blir anledning til å spørre og diskutere<br />

etterpå<br />

• Be likevel om at de sier det de lurer på underveis slik<br />

at det blir lettere å huske det til etterpå<br />

• Forklar om prototypensbeskaffenhet og hvordan den<br />

avviker fra virkeligheten<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


7: Beskriv oppgaven og produktet<br />

<strong>NTNU</strong><br />

• Beskriv de oppgavene du vil brukerene skal utføre<br />

• Legg en summarisk oppgaveliste ved siden av dem<br />

• Beskriv produktet/systemet<br />

• Pass på å ikke avsløre funksjonalietet eller operative<br />

begrep (objekter og relasjoner) som du ønsker<br />

feedback på<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


8: Spør om det er noe brukeren lurer<br />

på - kjør testen<br />

<strong>NTNU</strong><br />

• La brukeren komme til orde før testen starter<br />

• Kjør testen og vær da bare observatør - reflekter<br />

brukerens spørsmål tilbake til dem<br />

• Det er viktig å ikke gripe inn når ting går galt, men se<br />

om brukeren får tilstrekkelig informasjon til å komme<br />

seg på rett spor igjen<br />

• Ta detaljerte notater - bruk video om mulig<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


Under testen er det viktig å:<br />

<strong>NTNU</strong><br />

• Gi brukeren en tidlig følelse av suksess (lette oppgaver)<br />

• Presenter en oppgave av gangen (reduserer mental belastning)<br />

• Hold en avslappet atmosfære i testrommet (server kaffe/ta pauser)<br />

• Unngå forstyrrelser; lukk døren og sett opp lapp. Slå av telefoner<br />

• Aldri hint til brukeren om at hun gjør feil eller jobber sakte<br />

• Minimer antall observatører i rommet (sett opp monitor i rommet<br />

ved siden av)<br />

• Ikke la overordnede observere brukerne<br />

• Hvis forsøkslederen får en følelse av at testsituasjonen er<br />

belastende for brukeren: Avslutt forsøket<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


<strong>NTNU</strong><br />

• Observer testen upartisk, ikke la brukeren få en følelse av dine<br />

preferanser.<br />

• Vær oppmerksom på hvordan du sier ting og ditt eget<br />

kroppsspråk. Det skal svært lite til før brukerne aner hva du<br />

mener<br />

• Behandle hver enkelt bruker som et individ (ta pauser mellom<br />

brukerne)<br />

• Ikke redd brukerne når de sliter med et problem<br />

• Vær sikker på at brukerene er ferdig med oppgaven før du går<br />

videre (brukeren er ofte veldig usikker, selv om hun har utført<br />

den riktige responsen)<br />

• Interager med brukeren underveis for å sikre verbalisering<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


Når du interagerer med brukeren:<br />

<strong>NTNU</strong><br />

• Ikke vis at du er overasket (si for eksempel "hadde du forventet at<br />

det skulle skje?")<br />

• Fokuser på hva brukeren forventer når hun utfører en handling<br />

• Hold deg i bakgrunnen, og reflekter tilbake det brukeren har sagt.<br />

Hjelp brukeren med å uttrykke det de tenker<br />

• Bruk en passiv språkform<br />

• Hvis du avbryter brukeren, gjør diskusjonen kort. Spar lengre<br />

diskusjoner til etterpå<br />

• Vær oppmerksom på brukerens verbale og nonverbale responser.<br />

("var det problematisk?", "Hva tenker du på nå?")<br />

• Vær hele tiden på jakt etter å forså rasjonalen bak brukerens<br />

handlinger. Hvis brukeren indikerer en annen designløsning: følg<br />

opp dette.<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


<strong>NTNU</strong><br />

• Fokuser på ett moment av gangen<br />

• Ikke korriger problemer i produktet der og da<br />

• Hjelp brukeren bare som en siste utvei:<br />

– Når de er veldig "lost" eller veldig forvirret<br />

– Når oppgaven tydelig gjør brukeren ukomfortabel<br />

– Når brukeren er så frustrert at det er like før hun gir opp<br />

– Når det er en "missing link" i produktet<br />

– Under bugs eller krasj i systemet<br />

• Når du hjelper brukeren:<br />

– Ikke skyld på brukeren<br />

– Hjelp brukeren gradvis forbi problemet (det ligger mye<br />

verdifull informasjon i en slik situasjon)<br />

– Vær oppmerksom på at hjelpen også kan påvirke det som<br />

skjer senere i forsøket. Vær forsiktig!<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


9: Avslutt testen og samle løse tråder<br />

<strong>NTNU</strong><br />

• Avslutt testen når alle oppgaver er avsluttet eller tiden<br />

er oppbrukt<br />

• Svar på brukerens spørsmål<br />

• Diskuter ting dere fant interessant underveis<br />

• Be om en subjektiv vurdering og eventuelle forslag til<br />

redesign<br />

• La videoen gå!<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


– Etter testen:<br />

• Debrifing: Fortell brukeren at hun var til god hjelp. Snakk med<br />

brukeren om hvordan hun opplevde forsøket<br />

<strong>NTNU</strong><br />

• Hold brukeren anonym ved videre bruk av resultatene<br />

• Informer brukerne om at de kan bli informert om funnene hvis<br />

de skulle ønske det<br />

• Ikke vis videoopptak utenfor brukbarhetsgruppen uten<br />

brukerens tillatelse<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


• Noen punkter for gjennomføring av debreifingen<br />

<strong>NTNU</strong><br />

– 1. Begynn med å la brukeren få utrykke hva hun har på hjertet<br />

– 2. Begynn diskusjonen på "høyt" nivå (generelle aspekter)<br />

– 3. Beveg dere så mot mer konkrete aspekt<br />

– 4. Gå tilbake til punkter du evt. noterte deg under seansen<br />

– 5. Fokuser på å forstå problemene, ikke på å løse de<br />

– 6. Etter at alle aspekter er diskutert, åpne for innspill fra de<br />

andre i labben<br />

– 7. Hvis mulig, åpne for at brukeren kan komme tilbake for<br />

ytterligere informasjon eller innspill<br />

– Husk å fremdeles holde deg upartisk når dere diskuterer<br />

etterpå. Ikke si noe som gjør at brukeren føler hun må<br />

forsvare handlingene sine.<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


10: Bruk resultatene!<br />

<strong>NTNU</strong><br />

• Etter at alle testene er gjort:<br />

– Analyser “sammenbruddene”<br />

– List opp og priorieter problemene<br />

– Finn årsakene til de viktigste problemene<br />

– Let etter alternative design løsninger<br />

• Husk - hensikten med testen er input til redesign<br />

• Hensikten med prototypen er å ha materiale å teste<br />

• Tester der resultatene ikke brukes er bortkastet tid<br />

• Prototyper som aldri testes er bortkastet tid<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


Tolkning av ”sammenbrudd”<br />

<strong>NTNU</strong><br />

• Tre årsaker til ”sammenbrudd”:<br />

– Manglende funksjonalitet.<br />

– Manglende kommunikasjon om funksjonalitet.<br />

– Feil målgruppe (kunnskapskrav, fysiologi++)<br />

• Kilder til innsikt:<br />

– Observasjon av bruk.<br />

– Intervju etterpå.<br />

– Egne erfaringer.<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


Etiske aspekt ved brukbarhetstesting<br />

<strong>NTNU</strong><br />

• Selv om brukbarhetstesting ikke er farlig for<br />

forsøkspersonene, blir de likevel utsatt for et psykisk<br />

press, og det er derfor viktig før testen starter å:<br />

– Ha alt klart når brukeren kommer<br />

– Understrek at det er systemet som blir testet, ikke brukeren<br />

– Gjør oppmerksom på at produktet er nytt, og kan ha bugs<br />

– Informer om at brukeren kan trekke seg når som helst<br />

– Forklar hva som blir registrert under testen (introduser utstyr)<br />

– Forklar brukerne at resultatene er konfidensielle og hvordan<br />

de skal brukes<br />

– Vær sikker på at du har besvart brukerens spørsmål før testen<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/


<strong>NTNU</strong><br />

Noen oppsummerende poeng<br />

All testing er bedre enn ingen testing (spør noen på gangen…)<br />

Prototyper skal lages i løpet av timer og dager ikke uker og måneder<br />

Ikke kast bort tiden på å diskutere design spørsmål som kan testes<br />

Job iterativt: Design - Test - Design - Test - Design…..<br />

Trondheim, 2001<br />

http://www.design..ntnu.no/

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!