7.4 Brukertesting og evaluering

Problemet du ikke kan se selv

Du har jobbet med designet ditt i ukevis. Du kjenner hver knapp, hver meny, hver lenke. Og det er nettopp derfor du ikke lenger kan se det med friske øyne. Du vet jo hvor alt ligger -- så du klarer ikke å forestille deg at noen andre ikke gjør det. Dette er den blinde flekken alle designere har, og det finnes bare ett virkelig effektivt botemiddel: å la ekte mennesker prøve.

Brukertesting er det kraftigste verktøyet en UX-designer har. Det avslører problemer du aldri ville oppdaget på egen hånd. Og det overraskende er hvor lite som skal til -- forskning viser at allerede fem brukertester typisk avdekker rundt 85 prosent av brukervennlighetsproblemene. I dette kapittelet skal vi lære å planlegge og gjennomføre en brukertest, bli kjent med think-aloud-metoden, se på A/B-testing og heuristisk evaluering, og ikke minst lære hvordan vi analyserer funnene og gjør dem om til reelle forbedringer.

Slik gjennomfører du en brukertest

En god brukertest starter med planlegging. Først definerer du målet: hva er det du faktisk vil lære? Deretter lager du oppgaver -- og her er en viktig finesse. Du sier «Finn kontaktinformasjonen til skolen», ikke «Klikk på Kontakt-knappen». Hvorfor? Fordi i det andre tilfellet har du allerede fortalt brukeren svaret, og da tester du ingenting. Så rekrutterer du fem til åtte testpersoner fra målgruppen, og forbereder testmiljøet med et stille rom, en klar prototype og gjerne opptaksutstyr.

Under selve gjennomføringen begynner du med å ufarliggjøre situasjonen: «Vi tester prototypen, ikke deg.» Du gir oppgavene én om gangen, og så observerer du -- uten å hjelpe. Det er overraskende vanskelig å motstå fristelsen til å gripe inn når noen sitter fast, men nettopp der ligger den verdifulle innsikten. Du tar notater om hva brukeren gjør og sier, og avslutter med noen oppsummeringsspørsmål. Noen regler er gull verdt å huske: det finnes ingen feil svar -- alt brukeren gjør er nyttig informasjon. Du forklarer ikke designet under testen. Hvis brukeren står helt fast, noterer du problemet og går videre. Og du tester tidlig og ofte, ikke bare helt på slutten når alt allerede er bygget.

Tre måter å evaluere på

Den mest brukte metoden i en brukertest er think-aloud, eller å tenke høyt. Her sier brukeren høyt hva hen tenker, føler og gjør mens hen bruker prototypen. Lytt til et eksempel: «Okei, jeg leter etter timeplanen... Jeg ser en meny oppe... Hmm, ingenting som heter Timeplan... Kanskje under Min side? Ja, der er det! Men det tok litt tid å finne.» På sekunder får du innsikt i brukerens tankeprosess, og du avdekker forvirring og feilaktige antakelser du aldri ville fanget ved bare å se hva hen klikket på.

En helt annen tilnærming er A/B-testing. Her sammenligner du to versjoner av noe for å se hvilken som fungerer best. Versjon A har kanskje en grønn «Kjøp»-knapp, versjon B en rød, og målet er å se hvilken som gir flest klikk. Halvparten av brukerne ser den ene, halvparten den andre. A/B-testing egner seg best for mindre endringer på nettsider med mange brukere, fordi du trenger nok trafikk til å få statistisk sikre resultater.

Den tredje metoden krever ingen brukere i det hele tatt. Heuristisk evaluering er en ekspertvurdering basert på anerkjente brukervennlighetsprinsipper, kalt heuristikker. De mest kjente er Jakob Nielsens ti heuristikker, som blant annet handler om synlighet av systemstatus, samsvar mellom systemet og virkeligheten, brukerkontroll og frihet, konsistens og standarder, og feilforebygging. En ekspert går gjennom løsningen med disse prinsippene som sjekkliste og finner svakheter -- raskt og rimelig, men uten den ekte brukerens uforutsigbare oppførsel.

Fra rotete notater til konkrete forbedringer

Etter en runde med testing sitter du igjen med en haug av notater og observasjoner. Nå begynner det viktigste arbeidet: å gjøre kaoset om til klare beslutninger. Først samler du alt og leter etter mønstre -- problemer som flere brukere opplevde. Når tre av fem snubler på det samme stedet, er det ikke tilfeldig. Deretter kategoriserer du funnene etter alvorlighet. Et kritisk problem betyr at brukeren ikke klarer å fullføre oppgaven i det hele tatt. Et alvorlig problem betyr at brukeren strever mye, men til slutt finner en vei rundt. Et mindre problem er irriterende, men påvirker ikke selve funksjonaliteten. Så prioriterer du: de kritiske fikses først, deretter de alvorlige, og til slutt de mindre.

Ta en ekte testrapport fra en skolenettside som eksempel. Oppgaven var «Finn timeplanen for neste uke». Resultatet var avslørende: fire av fem gikk først til «Min side», der timeplanen ikke lå. Tre av fem prøvde søkefeltet. Bare én av fem fant den på første forsøk -- den lå nemlig under menyvalget «Skoledag». En av brukerne sa det rett ut: «Jeg hadde aldri gjettet at timeplanen lå under Skoledag.» Dette er et alvorlig problem, og anbefalingene følger naturlig: gi menyvalget et tydeligere navn som «Timeplan», legg en direktelenke på forsiden, og sørg for at søk faktisk returnerer timeplanen. Til slutt dokumenterer og rapporterer du -- du oppsummerer de viktigste funnene, beskriver hvert problem med observasjon og anbefalt løsning, illustrerer gjerne med skjermbilder eller video, og presenterer det for teamet. God dokumentasjon er det som gjør at innsikten faktisk fører til endring.

Oppsummering

Vi har sett at designeren har en blind flekk, og at brukertesting er det kraftigste verktøyet for å avdekke det vi selv ikke ser -- der allerede fem tester fanger rundt 85 prosent av problemene. Vi lærte å planlegge en test med mål og målrettede oppgaver, og å gjennomføre den ved å observere uten å hjelpe.

Vi ble kjent med tre evalueringsmetoder: think-aloud, der brukeren tenker høyt; A/B-testing, som sammenligner to versjoner; og heuristisk evaluering, der en ekspert vurderer løsningen mot anerkjente prinsipper. Til slutt så vi hvordan vi analyserer funnene ved å lete etter mønstre, kategorisere dem som kritiske, alvorlige eller mindre, og prioritere deretter -- før vi dokumenterer og rapporterer, slik at innsikten faktisk fører til et bedre produkt.