Jon Gunnar hadde fått i oppdrag å snakke om planlegging av brukertester og startet møtet med å vise en film av en evakueringstest for Airbus A380. Testen gikk ut på å se hvor lang tid det tok å evakuere 873 passasjerer. Det er mye vi kan ta med oss fra denne testen når vi skal planlegge en brukertest:

• Evakueringstesten var svært godt planlagt
• Man hadde veldefinerte suksesskriterier. Alle skulle ut av flyet i løpet av 90 sekunder
• Man hadde laget en relevant starttilstand og en realistisk kontekst. Det var mørkt, rotete på gulvet og halvparten av nødutgangene er låst uten at noen viste hvilke dette var.
• Testen ble gjennomført av veldefinerte målgrupper som representerte faktisk sammensetning av reisende. Man hadde f. eks.  40% kvinner og 35 % av testpersonene var over 50.

Videre snakket Jon Gunnar om sine erfaringer med planlegging av brukertester, både i Steria og i sin tidligere jobb hos Finn. Hans viktigste budskap var at for å gjøre en god brukertest, må man ha veldefinerte omforente mål med testen. Videre må testen utformes basert på formålet. For å illustrere dette poenget, hadde Jon Gunnar laget filmen ”Stein på stein”. I denne filmen understreket han følgende sekvensielle steg man må gjennom ved planlegging av en brukertest:

1. Definere formålet med testen
2. Identifisere hvilke funksjoner som skal testes
3. Bestemme hvilket system skal testes – hvor er funksjonaliteten tilgjengelig?
4. Identifisere målgruppene. Hvem er brukerne av de valgte funksjonene?
5. Bestemme seg for hva slags utstyr man skal bruke i testen. Ta utgangspunkt i utstyret de faktiske brukerne vil ha. Hvis de har stasjonær PC, ikke bruk en laptop i testen o.l.
6. Lage realistiske testoppgaver

Jon Gunnars innlegg førte til en interessant diskusjon hvor man blant annet snakket om når man bør gjøre en brukertest, hvor ferdig løsningen man brukertester må være, bruk av papirprototyper, hvor mye vekt man bør legge på å gjøre miljøet så realistisk som mulig, rekruttering av brukere, utforming av oppgaver og ”remote usability testing”. Noen av de nyttige tingene man kan ta med seg fra diskusjonen neste gang man skal kjøre brukertest er:

• En student hos Netlife Research har funnet ut følgende i forhold til prototyper: Så lenge løsningen inkluderer kjente interaksjonsprinsipper, er det uproblematisk å bruke low-fi prototyper som f. eks. papirprototyper. Innehar derimot løsningen nye interaksjonsprinsipper, er det nærmest umulig for brukerne å sette seg inn i hvordan disse fungerer på en low-fi prototype.
• Man kan rekruttere testpersoner ved å ringe venner og bekjente eller f. eks. ved å henge opp en plakat i heisen. Mange av deltakerne hadde dog best erfaring med bruk av rekrutteringsbyrå, som f. eks. Norstat. I tillegg til å rekruttere testpersonene i første omgang, følger også rekrutteringsbyråene opp at testpersonene møter opp og sørger for erstatter skulle noen likevel ikke komme.

Jostein Magnussen etterfulgte Jon Gunnar med et innlegg om moderering av brukertester. Jostein har gjennomført ”tusenvis” av brukertester og kom med følgende tips basert på sine erfaringer:

Gjør brukeren mindre, ikke mer nervøs. Tips for å skape en minst mulig nervøs atmosfære kan være:

• Pass på språkbruken din. Unngå for all del kliniske uttrykk som for eksempel ”test” og forsøk heller snillere synonymer som ”gjennomgang”.
• Tilby testpersonen noe å drikke og smalltalk litt før testen starter. Man kan for eksempel spørre om det gikk greit å finne frem og om testpersonen har vært med på slike undersøkelser tidligere.
• Pass på å si de tingene du må si. Dvs. varighet av testen, hva man får for å delta, at det går ikke på tid, at testpersonen skal prøve å gjøre som han/hun ville gjort hjemme, og sist men ikke minst: ”Det er ikke du som skal testes, men nettstedet!”
• Vær oppmerksom på testpersonens attribusjon og hvorvidt du har å gjøre med en person som legger skylda på seg selv, eller en som legger skylda på systemet. Hjelp gjerne testpersonen med å skylde på nettstedet.

Les opp rettighetene for testpersonen og be dem om å skrive under på papiret. Jostein har en mal for et slikt papir som han gjerne distribuerer om andre har behov for det!

Be testpersonen om å tenke høyt. For noen er dette veldig naturlig, for andre helt unaturlig. For å hjelpe dem, kan man ta opp et annet nettsted og demonstrere. Man kan minne testpersonen på det et par ganger i løpet av testen. Hvis man har å gjøre med en person som ikke klarer å tenke høyt, er det ikke vits i å mase om dette gjennom hele testen. Hvis man gjør brukertest med eyetracking er det litt mindre viktig å be dem om å tenke høyt.

Vis interesse:

• Lat som du tar notater selv om det sitter en observator i et annet rom og får med alt som skjer. Testpersonene reagerer positivt på at det de gjør blir notert.
• Unngå å si ”hm..” fordi det kan virke som en bekreftelse.
• Si ting som ”Ja, det skal vi ta med oss” (samme om man tar det med seg eller ikke) og ”Det er interessant”

Forbered deg spesielt hvis du skal teste med blinde og svaksynte

Vær fleksibel. Stort sett er det ikke noe poeng i å henge seg opp i at man skal gjennom alle oppgavene eller at alle får akkurat de samme oppgavene. Hvis det er nødvendig, juster oppgavene underveis. Be de som observerer om å notere om det er noe du bør gjøre annerledes som moderator.

Josteins siste råd på veien:

• Hvis brukeren roter seg bort, bør man ikke dvele for lenge med en oppgave, men gi brukeren et hint eller gå videre til neste oppgave.
• Hvis du har laget løsningen, anbefaler Jostein at man får en annen til å være moderator.
• Hvis de på observasjonsrommet maser om å få komme med innspill under testen, vær streng!
• Man kan ha observatører i samme rom hvis testpersonen er trygg, f. eks. en ekspertbruker. Ellers vil Jostein generelt ikke anbefale det. Dette avhenger selvfølgelig av antall observatører. Å ha én observatør i samme rom som tar notater kan være greit.
• Kjør pilottest og lær deg litt om domenet.
• Unngå å besvare spørsmålene som testpersonen kommer med. Øv deg på ”psykologrollen”, dvs. å svare testpersonens spørsmål med et nytt spørsmål.

I diskusjonen rundt moderering av brukertester var vi innom mange interessante tema. Et av dem var hvorvidt det er riktig å la testpersonen få hilse på de som er i observasjonsrommet. Her hadde folk litt ulike meninger og erfaringer. Jostein hadde varierende erfaringer, og hadde blant annet opplevd at de i observasjonsrommet har prøvd å gi tekniske forklaringer på hvorfor ting er som de er. Andre mente at testpersonen i følge norsk lov har rett til å møte de i observasjonsrommet. Et annet interessant tema som ble diskutert, var hvilken opplæring man skal gi testpersoner når man skal teste ekspertsystemer. Konklusjonen ble at man aller helst bør gi brukerne den opplæringen de skal få. I noen tilfeller har man sett at det er nødvendig å forberede testpersonen ved materiell man går gjennom eller ved at man går gjennom noen funksjoner. Men det ble også påpekt at man alltid vil få nyttige innspill ved en brukertest og  en brukertest av et ekspertsystem uten opplæring av testpersonene vil også gi innsikt i forbedringsområder.

Haakon Halvorsen snakket om observasjon av brukertester og startet sin presentasjon med den klassiske ”awareness test”, dvs. en film hvor tilskuerne blir bedt om å telle hvor mange ganger en gjeng basketballspillere sender pasninger. Samtidig går en dansende bjørn forbi spillerne. 50 % av tilskuere vil ikke oppdage bjørnen fordi de er så opptatt av å telle antall pasninger. Å være klar over menneskets tilbøyelighet til å sile ut informasjon på denne måten er nyttig å ha med seg når man skal være observatør av en brukertest. Det krever trening for å identifisere problemområder i en brukertest og å forstå hva som faktisk er årsaken til testpersonens problem.

Haakons tilnærming til brukertesting er at testteamet skal være ”mythbusters” som ødelegger myter om hvordan en løsning fungerer. Med utgangspunkt i ISOs definisjon av brukskvalitet, måles ofte ”effectiveness”, ”efficiency” og ”satisfaction” i en brukertest. Haakon advarer mot å fokusere for mye på ”effectiveness” og f. eks. suksessrate. Hvis en testperson har et problem, er det et problem. Man må huske på at brukertesting er en kvalitativ metode og at man ikke kan kvantifisere funnene ved f. eks. å si at 90 % ikke klarer å gjøre en oppgave selv om 9 av 10 ikke klarte det i brukertesten. Man bør vanligvis ikke fokusere for mye på ”efficiency” med tidtaking o.l. heller. I forhold til ”satisfaction”, mente Haakon at å spørre testpersonen om hvor godt de liker løsningen etter testen er helt bortkastet. Etter testen har testpersonen i følge Haakon ingen motivasjon for å komme med negativ tilbakemelding.

Til slutt kom Haakon med noen tips på veien:

• Vit hva du ser etter når du observerer en brukertest.
• Brukere skal sees, ikke høres. Ikke lytt til testpersonens hypoteser om hva de selv eller andre ville ha gjort.
• Noter banale hendelser og marker tidspunktet for når noe vesentlig skjer slik at det er lett å finne tilbake til det.
• En brukertest bør observeres av hele prosjektgruppen og representanter for kunden. Lag en regel om at kunden må overvære minst to tester.
• Observatører må bruke innestemme.

Alt i alt var det et interessant medlemsmøte. Det var stort engasjement og det føltes nyttig å dele erfaringer på tvers av firmaer. Mange tema ble kun berørt på overflaten, så det kan nok bli behov for flere medlemsmøter om dette temaet!

- Sigrun Lurås, styremedlem i BITS