8. september 2003

Brukertestet er ikke lik brukervennlig

Min kjære Mona skal holde foredrag om brukertesting på årets Yggdrasil-konferanse, og her er sammendraget av presentasjonen.

Brukertestet er ikke det samme som brukervennlig

Mona Sverrbo Halland,
Informasjonsarkitekt, Halogen AS

Om foredragsholderen
Mona Sverrbo Halland er informasjonspsykolog i konsulentselskapet Halogen AS. Hun er cand. polit i psykologi med spesialisering innenfor menneske-maskin kommunikasjon fra NTNU. De siste fem årene har hun jobbet med brukeranalyse, brukertesting og informasjonsarkitektur av interaktive og mobile løsninger og har gjennomført et hundretalls brukertester. Mona har også erfaring fra design av prosessgrensesnitt og kontrollrom for oljeindustrien og ulykkesanalyser innenfor jernbanedrift og oljeindustri.

Introduksjon
Brukertesting er svært viktig, men brukertesten har dessverre også en lei tendens til å bli en sovepute - en lettvint unnskyldning for ikke å gjøre tilstrekkelig grundig forarbeid i analyse- og konseptfasen.

”Vi skal jo brukerteste løsningen etterpå, så det trenger vi ikke å ta så nøye”, tenker man, som om brukervennlighet er noe som kan ”trylles fram” gjennom brukertesting. Dette er selvsagt feil, og hvorfor det er feil og hva som kan gjøres med det vil bli gjennomgått.

Selve testdesignet og gjennomføringen av brukertesten er også et minefelt av feilkilder, med mange muligheter til å påvirke testresultatet i gal retning. Feil under rekruttering, feil under utforming av oppgaver, for mye rettledning underveis og feilkilder i forbindelse med observasjon er noen av fallgruvene som gjennomgås i presentasjonen.

Og sist, men ikke minst, dersom ikke resultatene fra brukertesten blir fulgt opp i praksis blir tjenesten heller ikke mer brukervennlig. Resultater kan tolkes i mange retninger, og alt for ofte velger man enkleste løsning uten å oppnå en substansiell forbedring av brukervennligheten.

Dette foredraget tar for seg temaene:
• Når skal du teste?
• Hvordan skal du teste?
• Hvordan skal du bruke resultatene?

Målgruppen for presentasjonen er middels til avansert, dvs. at jeg går ut fra at tilhørerne har gjennomført brukertester tidligere og dermed er kjent med grunnleggende teknikker og metoder fra før.

Brukertest er en kvalitativ metode
Rolf Molich i det danske usability-firmaet DialogDesign [1] har gjennomført en rekke studier kalt Comparative Usability Evaluations (CUE) [2]. Formålet har vært å avdekke om ulike profesjonelle usability-byrå får de samme resultatene når de tester samme nettsted.

Resultatene har vært oppsiktsvekkende:

I CUE 2-studien fra 1998 fikk Molich sju profesjonelle team til å brukerteste e-posttjenesten hotmail.com. Det ble i alt funnet 300 feil i tjenesten, mens bare én feil ble funnet av alle syv teamene. Hele 76% av feilene ble bare identifisert av ett eneste team.

Hvordan er det mulig at resultatene spriker så voldsomt? Hovedforklaringen ligger etter mitt syn i at brukertesting først og fremst er en kvalitativ metode, mens resultatene svært ofte oppfattes som kvantitative.

Det er store ulikheter og svært forskjellig utgangspunkt for kvalitative og kvantitative metoder, stikkordmessig oppsummert nedenfor.

Kvantitative metoder:
• "Objektiv"
• Fokus på bredde
• Resultater i form av tall
• Kontroll på variabler
• Usynlig forsker
• Klassiske forskningseksperiment
• Survey

Kvalitative metoder:
• "Subjektiv"
• Fokus på dybde
• Resultater i form av beskrivelser
• Ulike variabler gir mer innsikt
• Deltagende forsker
• Dybdeintervju
• Feltarbeid

Det største problemet med kvantitative metoder er at vi kun kan måle det som lar seg kvantifisere. Subjektive opplevelser (som i brukeropplevelser) lar seg dårlig kvantifisere, selv om det for så vidt er mulig gjennom bl.a. strukturerte intervjuer og spørreskjemaer.

Brukertesting er således en metodisk "schizofren" aktivitet. Det tar utgangspunkt i klassiske forskningseksperimenter, men er egentlig kvalitative studier "pakket" inn i et skinn av kvantitet og objektivitet.

Brukertester ligger altså i et uklart grenseland, og dette skaper en del problemer og utfordringer. Disse skal vi gå systematisk gjennom ved å følge trinnene i en brukertest fra forarbeid til presentasjon av funnene.

Forarbeid (før test)
Alan Cooper bruker i boken The Inmates Are Running the Asylum [3] en lignelse der en snekker har laget en stol, mens oppgaven egentlig var å lage et bord. Han pusser og pusser med sandpapir, men uansett hvor mye han pusser vil han aldri klare å få stolen til å bli til et bord.

På samme måte hjelper det fint lite å brukerteste en tjeneste til perfeksjon, så lenge formålet med tjenesten er feil definert og f.eks. ikke hjelper brukerne med å løse det underliggende problemet. En brukertest har i all hovedsak liten verdi så lenge du ikke på forhånd har lagt grunnlaget for brukerfokusert design gjennom å snakke med eller på andre måter innhente data om brukerne, samt overført disse erfaringene via en konseptfase til en prototype som så blir gjort til gjenstand for brukertesting.

Eksempel: Statens Vegvesen - Trafikk til Gardermoen (nedlagt)

Det hjelper lite å brukerteste når:
- Brukerne har ikke behov for tjenesten i det hele tatt
- Det grunnleggende konseptet for tjenesten er feil

Mulige løsninger på problemene:
- Analyser brukssituasjoner
- Gjennomfør oppgaveanalyse
- Snakk med brukerne på forhånd!

Definisjon av målgrupper
Jeg blir stadig like sjokkert når målgruppene for en tjeneste ikke er avklart når tjenesten skal brukertestes. Har du ikke et bevisst forhold til hvem tjenesten skal nå ut til, eller målgruppen er "alle", så er sannsynligheten stor for at vi vil brukerteste tjenesten med feil personer.

Det er også viktig at du lager gode seleksjonskriterier for hvem som er med og hvem som skal utelukkes for deltagelse på testen.

Husk at viktigere enn antall testpersoner er HVEM du tester på.

Eksempler: "Bokklubbmedlem" som kriterium ved test av nettbokhandel, "bruker nettbank" som kriterium for å luke vekk ikke-nettbrukere.

Det hjelper lite å brukerteste når:
- Testpersonene ikke er relevante
- Målgruppen er ”alle”
- Du kun tar utgangspunkt i markedsavdelingens kriterier

Mulige løsninger på problemene:
- Finn felles behov på tvers av demografi
- Finn motivasjonsfaktorene for bruk
- Lag gode seleksjonskriterier

Rekruttering av testpersoner
Det er dessverre ganske vanlig å gjøre rekruttering på det man tror er "enkleste og billigste" måte: Man ringer selv rundt til venner og bekjente eller bruker folk i organisasjonen. Sannsynligheten for å teste på feil personer blir da svært høy, og nytteverdien av testen blir kraftig redusert. I verste fall vil resultatene være direkte feil. Min klare anbefaling er å bruke et profesjonelt rekrutteringsbyrå. Jeg mener å ha belegg for at det faktisk lønner seg økonomisk også.

Det hjelper lite å brukerteste når:
- Testpersoner representere ikke målgruppen

Mulige løsninger på problemene:
- Ikke la oppdragsgiver gjøre jobben
- Ikke gjør jobben selv
- Bruk et rekrutteringsbyrå
- Still strenge krav til rekrutteringsbyrået
- Sørg for at seleksjonskriteriene blir fulgt

Oppgavedesign
Det er typisk at vi tester det som enklest lar seg teste, og ikke nødvendigvis det vi bør teste. Feil i testdesignet, og særlig under konstruksjon av oppgaver, er kanskje den største enkeltårsaken til feilaktige resultater. Det typiske problemet er at man legger løsningen på problemet innbakt i oppgaveteksten, f.eks. ved å bruke samme navngiving som i menykategoriene. Andre vanlige problemer er at man tester oppgaver som ikke er relevante for brukerne, eller at man går glipp av viktig informasjon fordi man ikke lager oppgaver som er "åpne nok".

Eksempel: Kelkoo.com

Problemer med oppgavedesign:
- Ledende oppgaver
- Vi tester det som er viktig for oss selv (utviklere/designere/osv.)
- Vi tester det som har kostet mest å utvikle

Mulige løsninger:
- Lag realistiske brukerscenarier, og formuler oppgaver ut fra disse
- Bruk mest mulig åpne oppgaver, dvs. la brukerne formulere sine egne oppgaver
- Innled testseansen med å la testpersonen få vurdere tjenesten uten forstyrrelser først

Gjennomføring av testen
Både det å teste andre og det å bli testet setter folk i en kunstig, og litt merkelig situasjon. Det er utrolig lett for testleder å påvirke den som blir testet, både bevisst og ubevisst. Det er derfor viktig å trene på hvordan du snakker til testpersonene, hvordan du tar imot dem ved velkomst, hvordan du introduserer oppgavene og hvordan du guider gjennom hele testen. Her må det trenes. La andre kolleger observere deg.

Testpersonen på sin side har lett for å prestere enten mye bedre, eller mye dårligere enn normalt! Mye bedre fordi de vil gjøre et godt inntrykk og konsentrerer seg mye mer enn normalt, mye dårligere fordi mange kan bli nervøse og få "jernteppe".

Problemene rundt gjennomføring er knyttet til:
- Testlederrollen
- Testsituasjonen

Mulige løsninger:
- Vær ydmyk!
- Vær bevisst på egen oppførsel
- Test aldri alene
- Tren dere på hverandre

Observasjon under testen
Det å observere andres handlinger er fullstendig subjektivt. Det er viktig å huske på at det vi ser er vår fortolkning av det en annen person gjør, tenker og føler. Ulike testpersoner vil ha svært ulike strategier for problemløsning, og for hvordan de klikker seg rundt på et nettsted eller jobber med en applikasjon. Noen er fullstendig komfortable med å bruke lang tid på en oppgave, andre "forventer effektivitet". Det er derfor meningsløst å bruke stoppeklokke i en brukertest!

Det kan også være veldig vanskelig å forstå hva som er en mindre feil og hva som er et stort problem for brukeren. Det er derfor ekstremt viktig at definisjonen for problemer og feil er godt gjennomarbeidet på forhånd og at vi diskuterer fortolkningene med minst en annen observatør etter at hver test er gjennomført.

Problemer rundt observasjon er knyttet til:
- Hva er et problem? Hva er en feil?
- Hva oppleves som problem for denne testpersonen?
- Stor forskjell mellom det folk sier og gjør
- Samme person er testleder og observatør
- "Dess flere feil, dess flinkere er vi", jf. Molich's CUE-studier
- Kvantifisering, bruk av stoppeklokke

Mulige løsninger:
- Diskuter kriteriene for problemer og feil
- Kjenn dine egne briller: ALT er tolkning
- Test aldri alene
- Ha alltid med representanter fra oppdragsgiver
- Skill faktiske funn fra egne kommentarer

Rapportering av testresultater
En testrapport kan veldig lett oppfattes som en lang "fikseliste", med den uheldige konsekvens at oppdragsgiver da bare retter på det enkleste (lest billigste) og lar de alvorligste problemene være. Et konkret eksempel er at brukerne ikke skjønner hva tjenesten er, og finner heller ikke knappen for registrering. En fikseliste vil da kunne føre til at registreringsknappen blir flyttet, men fortsatt uten at brukerne skjønner hva de skal registrere seg for.

Det er også lett å fristes til å ta med egne betraktninger og forslag til løsninger i rapporten. Dette er for så vidt greit, så lenge egne meninger og testfunn skilles klart fra hverandre.

Eksempel: djuice.com

Problemer knyttet til rapportering:
- Konseptfeil kommer ikke frem i rapporten
- Rapporten oppfattes som en ren fikseliste
- Rapporten er en sammenblanding mellom funn, egne meninger og forslag til nye løsninger
- Kvalitative funn presenteres kvantitativt

Mulige løsninger:
- Dersom du finner alvorlige konseptfeil; vurder å kutte alt annet!
- Lag tydelig skille mellom funn og forslag til løsninger
- Ta med skjermdumper med forklaringer
- Ta med sitater fra testpersonene

Presentasjon av funnene
Det viktigste ved en presentasjon er at man får frem de viktigste funnene på en god og pedagogisk måte. Dette er en jobb som er mye enklere dersom oppdragsgiver har deltatt på testen. Kjernen i en brukertest er nettopp i å ha opplevd testpersonens lidelser eller gleder på nært hold.

Problemer knyttet til presentasjon:
- Folk tror du overdriver når tilhørerne ikke har deltatt på testen
- Tilhørerne oppfatter testpersonene som "dumme"
- Oppdragsgiver tviler på testens gyldighet på grunn av antall testdeltagere e.l.

Mulige løsninger:
- Ta alltid med oppdragsgiver på testen
- Redegjør for hvordan du har rekruttert
- Vis mange eksempler og skjermdumper
- Evt. kan du lage videoklipp med "høydepunkter", men dette er tidkrevende og blir aldri like bra som å ha vært til stede selv

Oppfølging etter testen
Det viktigste å huske på når du skal anvende resultatene fra en brukertest, er å være 100% klar over at resultatene er subjektive, fordi metodikken er kvalitativ.

Når det er sagt, er det ingen tvil om at resultatene fra en brukertest er det nyttigste verktøyet vi har for å produsere ekte brukervennlighet i interaktive løsninger.

Forutsetningen er imidlertid at vi faktisk kommer frem til de riktige resultatene (dvs. identifiserer de faktiske problemene) og ikke minst klarer å kommunisere disse til designere og programmere på en slik måte at egne betraktninger og forslag til løsninger fører til at man faktisk løser problemene, og at de ikke dukker opp igjen ved neste test av tjenesten.

Problemer knyttet til oppfølging:
- Fare for "godkjent-stempel" på brukervennlighet etter brukertest
- Resultatene oppfattes som fasitsvar (men er kvalitative)
- En brukertest kan drepe kreative diskusjoner
- Vi endrer likevel bare på det som er lett å endre
- Brukertesten kommer for seint i prosessen

Mulige løsninger:
- Test tidlig, og test ofte
- Kjenn testens mulige feilkilder
- Bruk resultatene som en veiledning, ikke som eneste fasitsvar
- Ta de tunge avgjørelsene for endring
- Legg ned hele tjenesten om nødvendig

Konklusjon
Brukertesting er fremdeles den beste metoden for å få kvalitets- og realitetstestet tjenesten.
Men summen av ubevisste feil kan lett gi et direkte feilaktig resultat - og føre oss på ville veier.

Brukertesting er bra, men gir ikke automatisk en brukervennlig tjeneste, fordi:
• Forundersøkelser og analyse er minst like viktig som brukertesting
• En brukertest er subjektiv, og har mange feilkilder


10 teser om brukertesting:
1. En brukertest er et mektig redskap, som også kan misbrukes!
2. Det som kan måles, blir målt!
3. Det som kan beskrives, blir beskrevet!
4. En tjeneste blir ikke automatisk mer brukervennlig selv om vi tester aldri så mye!
5. Folk er forskjellige!
6. En brukeropplevelse (god eller dårlig) er subjektiv, og kan i utgangspunktet ikke kvantifiseres
7. De som ikke var til stede på testen, har heller ikke forutsetninger for å forstå resultatet (50% av verdien ligger i testen)
8. Test tidlig, test ofte!
9. Bruk aldri stoppeklokke!
10. "Fikselister" kan fungere som ”plaster på såret” - det hjelper lite hvis pasienten har kreft!


Tommelfingerregler for brukertesting:
1. En grundigere forundersøkelse er viktigere enn brukertest
2. Still klare krav til når testene gjennomføres
3. Bruk et rekrutteringsbyrå for å sikre representative brukere
4. Ikke gjennomfør testen alene
5. Diskuter hva som er observasjonskriteriene
6. La andre observere deg - tren på testen
7. Still krav om at oppdragsgiver er tilstede på testen
8. Ikke lever en overforenklet fikseliste som testrapport
9. Ikke kvantifiser resultatene
10. Ta med mange sitater og kommentarer fra testpersonene

Dette er mine 10 viktigste tips til bedre brukertesting. Hele denne artikkelen, selve presentasjonen min samt ytterligere kommentarer finner du også elektronisk på nettstedet www.brukaropplevingar.com [4].

Vil du ha enda mer anbefaler jeg bl.a. rapporten "230 Tips and Tricks for a Better Usability Test" [5].

Referanser
1. DialogDesign / Rolf Molich
http://www.dialogdesign.dk/
2. Comparative Usability Evaluation (CUE)
http://www.dialogdesign.dk/cue.html
3. Alan Cooper: The Inmates Are Running the Asylum (1999)
4. Brukaropplevingar.com
www.brukaropplevingar.com
5. Nielsen Norman Group: "230 Tips and Tricks for a Better Usability Test"
www.nngroup.com/reports/tips/usertest

08.09.2003, 19:58 in Brukartesting, Mona sine ting | Fastlenke

Kommentarar

Tilbaketråkk

Tilbaketråkk-URL for dette innlegget:
http://www.typepad.com/services/trackback/6a00d83455881869e200d83537859869e2

Bloggar som refererer til Brukertestet er ikke lik brukervennlig: