Fem tips til deg som skal gjennomføre brukertester

Det er ikke alltid lett å vite når du skal gjennomføre en brukertest, hvem du skal utføre testen med, hvordan oppgavene skal utføres eller hva du som testleder skal gjøre under en brukertest. I dette innlegget får du en kort intro til hva det er viktig å tenke på når du skal gjennomføre brukertester.

Ordet brukertesting kommer fra det engelske begrepet «usability testing» som beskriver konseptet bedre enn det norske begrepet. Det handler altså om å teste brukervennligheten til løsninger og tjenester, og ikke å teste hvor gode testdeltakerne er til å bruke en gitt løsning. Brukertesting er en metode som brukes for å avgjøre hvor enkelt og intuitivt for eksempel et nettsted er å bruke. Testene utføres med reelle brukere, som utfører reelle oppgaver på skisser eller ferdige tjenester mens de blir observert. Ved gjennomføring av brukertester vil du med stor sannsynlighet spare sluttbrukerne for mye frustrasjon. 

Når du skal gjennomføre brukertester bør det foreligge en behovskartlegging, og én eller flere hypoteser om hvordan den endelige løsningen skal fungere. Men det er også viktig at du på forhånd har avklart hvorfor brukertesten gjennomføres, hva målet med testen er og hvor mye tid som skal settes av etter testen til å fikse eventuelle problemer med og i løsningen. Denne kartleggingen gir det et grunnlag for hvor omfattende brukertesten skal være, og ikke minst hva det er viktig å teste i den fasen av prosjektet du er i. Nedenfor følger fem tips til deg som skal gjennomføre brukertester.

1. Test tidlig

Selv en enkel test på papirskisser gir deg en pekepinn på hva som vil fungere og ikke fungere i løsningen din. Det er ofte billigere og enklere å lage en skisse på papir enn det er å lage en interaktiv skisse på en datamaskin. Ved å teste på papir tester du konseptet eller flyten og oppbyggingen fremfor det endelige designet. Når en test gjennomføres på papir får du informasjon om brukerne ser alle mulighetene som finnes i grensesnittet, og om de forstår hva de forskjellige funksjonene gjør. Ettersom brukerne har mindre muligheter til å teste et grensesnitt ved å klikke seg frem og tilbake på papir enn på en datamaskin er det viktig å stille åpne spørsmål underveis. For eksempel kan du spørre om hva de forventer å se på et gitt skjermbilde fremfor å spørre om de ser en spesifikk funksjon.

I tillegg til at testing på papir gir indikasjoner på hva som fungerer og ikke er det også billigere å fikse eventuelle problemer som avdekkes ved tidlig testing. På dette stadiet i designprosessen er det enda ikke utviklet noe i form av kode eller interaktive skisser, så det er en forholdsvis liten jobb å skissere opp en ny løsning før den overrekkes utviklerne. Som bildet under viser vil det være fordelaktig å teste gjennom hele designprosessen for å forsikre seg om at man alltid designer en enkel og intuitiv tjeneste. Dersom dette ikke er mulig er det bedre med litt brukertesting enn ingen brukertesting. Så test tidlig fremfor å ikke teste i det hele tatt!

Testing i flere ledd gjennom designprosessen.

2. Test med reelle brukere

Ikke test på deg selv eller noen andre i prosjekt- eller utviklergruppen. Dette er personer som vet hva som ligger bak de forskjellige designvalgene, og hvordan løsningen er tenkt brukt. Brukervennligheten kan kun måles om den blir testet på målgruppen til løsningen. Dette betyr at et system for barn må testes av barn, og et system for eldre må testes av eldre.

I 2016 laget vi en mobilapplikasjon til bruk på sykehuset av pasienter som en del av et forskningsprosjekt om underernæring ved UiO. For å få innsiktsfull data om den aktuelle løsningen måtte vi besøke pasientene på sykehuset. Vi kunne ha funnet den samme målgruppen i andre settinger, f.eks. et eldresenter, men settingen er også viktig. En person som ligger på sykehuset er omringet av helt andre omgivelser, tanker og stimuli enn en person som oppholder seg på et eldresenter. Så dersom det er mulig bør brukerne oppsøkes i det miljøet løsningen er ment brukt for å få de mest representative dataene.

3. Bruk åpne scenarier

Ha nøytrale og åpne scenarier og spørsmål slik at du ikke leder testdeltakerne i en bestemt retning. Nedenfor følger noen eksempler på gode og dårlige testscenarier:

  • Dårlig: «Søk etter Rikke Julie Foss-Pedersen i personsøket»
  • Bra: «Du ønsker å komme i kontakt med Rikke Julie Foss-Pedersen. Hva gjør du for å løse dette?»
     
  • Dårlig: «Søk om å bli enkeltemnestudent»
  • Bra: «Du har ikke fått studieplass ved UiO gjennom det ordinære opptaket. Finn ut hvordan du likevel kan ta ett eller flere emner ved UiO.»

Det er ofte flere måter å løse en oppgave på, så det er viktig å stille åpne scenarier slik at brukerne kan løse oppgaven slik de vil. I eksemplene ovenfor er det hvert fall 3-4 måter å løse hver av oppgavene på. Men ved å si «Søk etter Rikke Julie Foss-Pedersen i personsøket» har du allerede fortalt deltakerne nøyaktig hva de skal gjøre. For å se hvordan de faktisk bruker løsningen er det bedre å be dem om å komme i kontakt med noe eller noen konkrete personer eller f.eks. avdelinger. Da kan brukerne selv finne ut av hva de må gjøre for å finne denne informasjonen.

4. Observer og lytt til brukerne

Som det kort ble nevnt i innledningen bør en brukertest utføres ved at man observerer brukerne uten å veilede dem underveis. Ofte utfører man testene med en eller flere hypoteser om hva som fungerer, og hva som ikke fungerer. Det er nettopp derfor man tester. Men det er viktig å legge fra seg alle følelser og meninger utenfor testrommet og gjennomføre testen på en subjektiv måte. Om du er for involvert i produktet som testes kan det være lurt å be noen andre gjennomføre testen, mens du selv observerer.

Legg igjen egne meninger og følelser utenfor testrommet.

En god strategi er å be brukerne tenke høyt underveis. Slik kan du både observere, lytte og bruke testen til å forstå hva det er som skjer underveis. Ettersom det kan være vanskelig å både lede, observere og notere under en brukertest kan det være nyttig å ha med en medhjelper som f.eks. har som hovedoppgave å kun observere og notere. Ved å ha med en medhjelper har du også en å diskutere resultatene med etter testen, og kanskje den ene fikk med seg noe vesentlig som den andre gikk glipp av.

Det er viktig at du observerer hva brukerne gjør under testen, og ikke kun hører på hva de sier. Det hjelper deg ingenting hvis 5 av 5 testdeltakere sier at de liker designet, men kun 1 av 5 klarte å løse oppgavene underveis i testen. Så da er spørsmålet: Når skal man lytte til brukerne? Dette svarer Jakob Nielsen på i sin artikkel fra 2001:

Only after they have used a design and have a real feeling for how well it supports them. 

Det kan være flere grunner til at det er en mismatch mellom hva deltakerne sier og hva de gjør. For eksempel kan det være at de ikke ønsker å tråkke noen på tærne. Det er uvant og rart å sitte og fortelle designerne av et produkt at det er dårlig, ikke fungerer eller rett og slett bare ser stygt ut. Eller kanskje de ønsker å fremstå som flinke? Vi har gjennomført flere tester der brukerne strever med å utføre en oppgave, ikke finner frem til funksjonaliteten, eller rett og slett ikke klarer å løse oppgaven for så bare å si: «Dette var jo egentlig ganske lett» når vi ber dem fortelle hvordan de syntes det gikk. Før hver brukertest er det derfor viktig å si at det er systemet som testes, og ikke brukerne. Hvis det er noe som er vanskelig å løse er det løsningen det er noe galt med, ikke brukerne.

I motsetning til meninger er oppførselen til brukerne ærlig. Hvis en person ikke klarer å utføre en oppgave er dette et direkte problem med designet. I kontrast kan en bruker si at de misliker noe ved designet, uten at de hadde problemer med utførelse av oppgaven. Hva man liker og ikke liker er forskjellig, og neste deltaker kan fort si at han eller hun elsker designet.

5. Fiks problemene

Etter endt(e) brukertest(er) er det på tide å fikse problemene. Det vil antageligvis være mye som er avdekt, så notatene fra brukertestene må først analyseres før de oppsummeres, struktureres og prioriteres. Prioriter problemene etter alvorlighetsgrad, og hva som er mest vesentlig å få på plass i en første versjon. Det er ikke sikkert det er åpenbart hvordan alle problemer kan løses, eller hva som er den beste løsningen på et problem. I disse tilfellene vil det være nødvendig å teste igjen. Det er ikke nødvendig å kjøre en ny stor brukertest for å teste spesifikk funksjonalitet, så skisser opp ny løsning for det aktuelle problemområdet og test dette isolert. Dersom det er helt åpenbart hva et problem var, og hva som skal til for å løse dette, er det ikke nødvendig å teste dette igjen.

Etter gjennomført brukertest kan det hende du blir møtt med kommentarer som: «Men brukerne vil lære seg å bruke funksjonalitet X». Det har skjedd meg, og på et tidspunkt vil det kanskje skje deg. Og det utsagnet er ikke nødvendigvis feil, brukerne vil lære seg å bruke en løsning eller en tjeneste hvis de bruker den ofte nok. Men dersom man kan unngå frustrasjonen en bruker opplever når de må lære seg å bruke noe som bør fungere ut av boksen, vil han eller hun sitte igjen med et mye bedre inntrykk av tjenesten når det han kom for å utføre er utført. Ettersom slike kommentarer kan oppstå er det, som nevnt i innledningen, på forhånd av en brukertest lurt å avklare hvorfor brukertesten gjennomføres, hva målet med testen er og hvor mye tid som skal settes av etter testen til å fikse eventuelle problemer med og i løsningen.

Oppsummering

Å gjennomføre brukertester kan ofte oppleves som frustrerende og ikke minst slitsomt. Du tester kanskje en løsning du selv har vært med å designe, og det er ganske trist å se at det du selv mente var en god løsning ikke er forståelig for sluttbrukerne. Men ved å teste vil du spare brukerne for mye slit og frustrasjon når endelig løsning går på lufta. Du kan sitte igjen med en god følelse over at løsningen er designet med brukerne i fokus, og at de viktigste oppgavene i tjenesten er lett å bruke for de aller fleste.

Les mer om brukertesting

Nielsen, J. (2001) First Rule of Usability? Don't Listen to Users. NN/g Nielsen Norman Group. URL: https://www.nngroup.com/articles/first-rule-of-usability-dont-listen-to-users/

Toftøy-Andersen, E. og Wold, J. G. (2011) Praktisk brukertesting. Cappelen Damm Akademisk

 

Emneord: brukeropplevelse, brukervennlighet, brukertesting Av Rikke Julie Foss-Pedersen
Publisert 24. aug. 2017 12:10 - Sist endret 9. jan. 2018 16:25
Tegneblokk med håndtegning av et brukergrensesnitt

UX-bloggen

En blogg for deg som er interessert i gode brukeropplevelser, tips og triks, nyttige UX-verktøy og erfaringer fra prosjekter vi i Gruppe for Brukeropplevelse arbeider med.