Hvorfor brukerteste?

Det er mange gode grunner til at vi alltid bør brukerteste de tjenestene vi lager.

Ved å brukerteste får du...

• Kunnskap (istedenfor spekulasjon og hypoteser) om hvordan tjenesten din fungerer. Om testpersonene feiler på oppgavene de kom for å løse, er det stor fare for at brukerne dine vil feile også.

• Diskusjons- og konklusjonsgrunnlag for designavgjørelser, slik at hele teamet er bedre rustet til å gjøre gode valg i endring og videreutvikling av tjenesten.

• Enighet om hvilke behov tjenesten skal dekke. Er funksjonaliteten den samme som brukerne ønsker seg?

Så. Der har du det. Test alt. Alltid!

Før du begynner...

I korte trekk må du sørge for disse tingene før en brukertest:

1. Rekruttere testpersoner. Dette bør gjøres i god tid før selve testen. Du trenger ikke flere enn fem testpersoner, men det kan være lurt å ha én eller to i backup.

2. Lag manus og brukeroppgaver. Dette bør gjøres senest dagen før selve testen. Oppgavene lages for å avdekke om brukerne får til å gjennomføre det de kommer for å gjøre. Oppgavene du lager bør være mulig å løse i prototypen.

3. Invitér observatører. “Eieren” av løsningen (som oftest kunden, representert ved et prosjektteam) samt hele teamet som jobber med løsningen bør observere hele brukertesten. I tillegg bør du invitere alle stakeholders til observering. Stakeholders har som oftest ikke tid til å delta som observatører under hele testen, men de bør i hvert fall få med seg deler av testen. Vær tidlig ute med å invitere observatørene.

4. Forbered det tekniske. Du bør booke et mindre rom til å gjennomføre selve testen, og et større rom til observatørene. Lyd og bilde bør overføres direkte til en skjerm inne hos observatørene. Om du er usikker på hvilket utstyr du trenger, sjekk denne guiden. Dagen før testen bør du gå gjennom hele testopplegget og sørge for at alt det tekniske fungerer som det skal.

5. Ha papirene i orden. Sørg for at du har skrevet ut manus, observasjonsark, avtale om brukertesting, bekreftelse på mottatt gavekort og at du har selve gavekortene. Disse bør ligge inne på testrommet før testen starter.

Rekruttering av testpersoner

Du bør investere litt tid i å rekruttere de riktige testpersonene slik at du får det meste ut av brukertesten. Her er noen tips:

• Om du skal teste en “kom i gang”-opplevelse til en tjeneste bør du finne folk som er innenfor målgruppen til løsningen og som ikke har brukt tjenesten før.

• Om du skal teste konvertering (f. eks. i en nettbutikk) eller brukervennligheten til en tjeneste, bør du finne både folk som har brukt tjenesten før (hvis den finnes) og folk som er i målgruppen, men som enda ikke har brukt tjenesten.

Til selve rekrutteringen kan du bruke et rekrutteringsbyrå. Da er det viktig at du har fylt ut et tydelig rekrutteringsskjema på forhånd, slik at byrået finner de riktige testpersonene.

Du kan også rekruttere selv, f. eks. ved å etterlyse testpersoner på nettstedet deres, Facebook-sider, Twitter, Instagram eller e-poster dere sender ut. Ordlyden kan være noe sånn som dette:

“Ønsker du å gi oss tilbakemelding?“

...med lenke til en lengre beskrivelse av brukertesten.

Du kan også oppsøke brukerne dine der de er, og gerilja-teste tjenesten der og da, f. eks. med en medbrakt tablet eller smartphone. Det kan være vel så nyttig! Observering blir gjerne litt vanskeligere, men ta med deg en kollega og gjør gode notater mellom hver test. Husk sjokolade til testpersonene!

Manus og brukeroppgaver

Når du skal lage manus til brukertesten bør du ha som mål å 1) finne ut mer om testpersonen og 2) finne problemer i tjenesten teamet har jobbet med. Her får du noen tips til selve intervjuet:

Vennlig velkomst

Noe av det aller viktigste når man skal gjennomføre en brukertest, er å få testpersonen til å føle seg avslappet. Om testpersonen er ukomfortabel under testen, vil det gjenspeiles i testresultatene og mye av poenget med testen vil være borte.

“Takk for at du kunne være med på denne brukertesten. Har du vært med på noe tilsvarende før?”

“Jeg kan forklare litt hvordan det fungerer. Når vi utvikler nye løsninger og ny design, vil vi før eller siden komme til det stadiet hvor det er verdifullt å få noen nye øyne på løsningen vi lager - det er derfor vi trenger din hjelp :)”

“Før vi begynner, må vi gå igjennom et par formelle punkter. Alle som vi utfører brukertester med, må godkjenne disse punktene før vi begynner.”

Gå deretter gjennom avtalen om brukertesting med testpersonen. Bruk god tid på å gå gjennom avtalen og legg spesielt vekt på det siste punktet, om at testpersonen skal behandles høflig og med respekt - det pleier å være en fin “ice-breaker”.

“Først vil jeg stille deg noen spørsmål, og deretter vil jeg vise deg løsningen teamet har jobbet med. Jeg kommer til å stille en god del spørsmål, men jeg vil ikke at du skal føle at det er deg vi tester - det er løsningen vi tester. Vi vil finne ut om den nye løsningen fungerer bra, og det gjør vi ved å teste løsningen på deg. Om det er noe som ikke fungerer så bra, så er det vi som har gjort en feil - ikke deg :) “

“Måten vi gjør det på, er at vi om noen få minutter vil vise deg den nye løsningen teamet har jobbet med, og deretter be deg om å løse noen oppgaver.”

Finn ut mer om testpersonen

“Aller først vil vi stille deg noen spørsmål.”

1. Hvor er du fra?

2. Hva jobber du med?

3. Hva gjør du når du ikke jobber?

4. etc.

Still oppfølgingsspørsmål og forsøk å gradvis vinkle spørsmålene inn på ting som er relevant ift. løsningen som du skal teste. Om du f. eks. jobber med en ny nettbutikk, kan du stille spørsmål som “Pleier du å handle på nett?” og “Hvilke nettbutikker bruker du?” og “Hva er typiske ting du ikke handler på nett?”

Introduser prototypen

Merk: Det kan ikke sies for ofte hvor viktig det er å ikke la testpersonen sitte igjen med inntrykket av at det er han/hun som blir testet – det er løsningen vi tester, ikke testpersonen.

Et mål bør være å overbevise testpersonen om at hvis noe går galt underveis, er det prototypen det er noe galt med – ikke testpersonen. Da blir det lettere for testpersonen å være ærlig under testen.

“Det vi skal vise deg nå, er en prototype av den nye løsningen vi har laget for (...) Ettersom dette kun er en prototype, er det noen ting som vil virke og andre ting som ikke vil virke. Vi vil bare at du skal forsøke å bruke løsningen slik du ville gjort når du var hjemme for deg selv. Selv om det ikke er så enkelt, vil jeg at du skal late som om jeg ikke er her!”

“Jeg vil bare understreke (igjen) at det er løsningen vi tester – ikke deg. Jeg kommer til å stille deg en del spørsmål, men det finnes ingen rette eller gale svar. Vi skal bare prøve løsningen og se hvordan det går, og høre hva du tenker om den. Derfor er det bra om du kan forsøke å tenke høyt underveis. Høres det greit ut? :)”

Gå gjennom brukeroppgavene

Nå har vi kommet til stadiet hvor du faktisk tester tjenesten på testpersonen. Du må utarbeide et eget sett med brukeroppgaver til hver tjeneste du tester. Her finner du et eksempel på manus og brukeroppgaver vi lagde til brukertest av nytt nettsted for DEFA.

Når du gjennomfører testen, er det viktig at du stiller åpne spørsmål som f. eks. "Nå som du har sett (...), hva tenker du?".

Om du tester et nytt konsept, bør du prøve å finne ut om testpersonen forstår konseptet, i tillegg til å gjennomføre oppgavene. Du kan f. eks. stille spørsmål som “Hva dreier denne tjenesten seg om, tror du?” og “Kjenner du til noen lignende tjenester, som gjør det samme?”

Om testpersonen sliter et sted, still spørsmål som "Hva skjedde nå?" og "Hva hadde du forventet skulle skje?"

Unngå å stille ledende spørsmål som f. eks. "Synes du det var lett å gjennomføre alle stegene?" og "Ville du kjøpt produktene etter å ha gjennomført alle stegene?". Da får testpersonen gjerne lyst til å svare "riktig", og det vil vi ikke – vi vil vite hvor ting faktisk går galt og hva vi kan gjøre bedre.

Det er også en god idé å unngå "ja og nei"-spørsmål, ettersom vi vil vite hva testpersonen tenker. Åpne spørsmål som starter med “Hvem”, “Hva”, “Hvor”, “Når”, “Hvorfor” og “Hvordan” fungerer best!

Kjapp debriefing

Etter at alle brukeroppgavene er gjennomført, bør du la testpersonen oppsummere litt av det dere har gått igjennom.

Du kan stille åpne spørsmål som dette:

1. Hva tenker du om løsningen du nettopp testet?

2. Hva likte du?

3. Hva likte du ikke?

Til slutt takker du testpersonen for at han/hun tok seg tid til å gjennomføre testen, gir vedkommende et gavekort (husk å få signatur på mottatt gavekort!) og følger testpersonen ut.

PS: Du finner kortversjonen her – en disposisjon til brukertest. Den kan være fin å bruke under selve brukertesten i stedet for et manus.

Til observatørene

Om du skal observere under en brukertest, bør du ha dette i tankene:

Fokuser på problemer – ikke detaljer.

Det er både slitsomt og lite interessant for den som skal lese notatene om du noterer alt testpersonen sier og gjør. Du bør ha målene for tjenesten friskt i minne og forsøke å fokusere på ting som det er kritisk at brukerne får til under testen.

Følg med på hva testpersonen gjør – ikke sier.

F. eks. kan det være at testpersonen sier noe sånn som “men dette var jo enkelt!” samtidig som du ser at testpersonen har feilet fullstendig på oppgaven. Tilsvarende kan det være testpersonen sier noe sånn som at “dette virket veldig komplisert og vanskelig” eller “jeg liker ikke dette designet”, men så ser du at testpersonen har bestått alle oppgavene med glans på første forsøk.

Skriv ned alle misforståelser

Situasjoner der testpersonen sitter igjen med inntrykk av å ha løst oppgaven, men faktisk ikke har løst oppgaven, er spesielt interessante. Bekreftet testpersonen bestillingen? Ble skjemaet innsendt? Leser han/hun riktig artikkel? Sitter testpersonen igjen med riktig inntrykk av tjenesten? Når en testperson mener han/hun har fullført oppgaven, bør du følge spesielt nøye med.

Ta vare på gode sitater

Om en testperson sier noe “på kornet” som beskriver et problem (eller noe som fungerer veldig bra!) noter deg hva som ble sagt og uthev sitatet i observasjonsarket. Med ekte sitater fra ekte brukere er det lettere å overbevise dem som ikke har vært observatører under testen, om at noe fungerer eller ikke fungerer.

Se etter mønster

Sliter testpersonene på de samme stedene? Merk deg disse situasjonene og prioriter disse problemene når du skal jobbe videre med tjenesten. Om kun én av testpersonene støter på et alvorlig problem, bør du ta tak i dette også.

Under testen bør alle observatørene benytte det samme observasjonsarket. Lag en kopi av regnearket og lag én fane til hver observatør i det nye regnearket (du kan bare kopiere den første fanen)

Vær kort og konsis i dine notater. Disse tingene bør du notere:

1. Kilde (hvilken testperson?)
   Eksempel: TP1 og TP3
   
   

2. Hvilken side/modul/element observasjonen gjelder
   Eksempel: Hovedmenyen i headeren

3. Kort beskrivelse av problemet (maks én setning)
   Eksempel: Trykker ofte på feil menyvalg.
   
   

4. Forslag til løsning
   Eksempel: Lag menyvalgene litt større og gi de litt mer luft.

Bare notere – ikke kommentere

Det kan være fristende å kommentere det som skjer underveis i en brukertest, spesielt hvis du har vært med på å lage tjenesten. I stedet for å kommentere, bør du la de andre observatørene konsentrere seg. Dessuten unngår du å starte en diskusjon under brukertesten, noe som i verste fall vil føre til at ingen av observatørene får med seg det som skjer under testen.

Etter hver test

Benytt pausene mellom hver testperson til å diskutere problemer som testpersonene opplevde. Sammen som team bør dere også analysere observasjonene. Dette gjøres i fire steg:

1. Hvor store konsekvenser har problemet/feilen for brukeren?
   A = får ikke utført oppgave
   B = får utført, men med problemer
   C = småfeil, kosmetisk

2. Skal vi gjøre noe med dette eller ikke?
   Teamet bør vurdere om problemet er stort nok til at det må gjøres noe med. Om svaret er ja, bør problemet legges inn i en backlog.

3. Prioritering!
   Alle problemer som legges inn i en backlog bør prioriteres på en skala fra 1 til 5, hvor 1 er viktigst.

4. Hvem løser problemet?
   Allerede nå kan det være en god idé å avgjøre hvem som skal løse problemet. Den som løser problemet bør gå igjennom alle forslag til løsning relatert til problemet som ble notert.

En på teamet, som oftest en prosjektleder eller rådgiver, bør ta ansvar for at problemene blir fulgt opp i etterkant av testen.

Til teamet

En av teammedlemmene som er med som observatør under hele testen, bør ta ansvar for analyse, prioritering og oppfølging underveis i testen.

Det vil antagelig være mange duplikater i observasjonene som er notert, så mye av jobben består i å slå sammen observasjoner som er like og lage én liste med alle unike observasjoner. Dette kan godt være en egen fane i regnearket som er forbeholdt den som er ansvarlig for analysen.

Neste steg består i å “shorte” denne listen slik at alle uvesentlige observasjoner tas ut. Dette bør også være en egen fane i observasjonsarket som heter “Shortlist”, slik at vi ikke mister noen av observasjonene.

Nå sitter du igjen med en prioritert shortlist over problemer som teamet skal løse, og du er flere skritt nærmere en mer brukervennlig tjeneste. Hurra!