Når man planlegger brukertest er det fort gjort å undervurdere observatørenes rolle. At det er kjekt å ha opptil flere observatører er alle enige om, men hvem bør observere, og hva skal vi forvente av dem? Hvor mye forkunnskap bør de ha? Observatørene kan være nøkkelen til å få gjennomslag for forbedringer. Du må sørge for at de hjelper til med notater og at de ikke blir passivt publikum som legger stein til din byrde. Gjør du forarbeidet riktig, vil du kunne gjøre ambassadører av observatørene. Her er mine erfaringer som testleder om hvordan du får mest mulig nytte av observatørene dine.
Ikke alle kan komme
Du må håndplukke de du vil ha: Systemeier, prosjektleder og andre beslutningstagere er viktigst. Ofte må du ha med en utvikler eller to. Ved å få utviklere til å observere bruken av systemer de har laget vil de bli motivert for oppgaver som kan være komplisert å utvikle men som vil gi økt brukskvalitet. Utviklere er i min erfaring svært dyktige til å se løsninger på problemene de observerer.
Book folk tidlig
Dersom beslutningstagere ikke observerer testen, vil de alltid trekke i tvil dine konklusjoner når du presenterer dine funn. Har de vært der selv, blir de ambassadører for brukskvalitet. Hold aldri en brukertest uten å forsikre deg om at beslutningstagere får være med.
Observatørene må ta del i planleggingen
En god testplan er arbeidet frem av flere. Det nytter ikke å planlegge testen på egenhånd og deretter invitere observatører. Beslutningstagerne for ditt system eller prosjekt må være enige i hva som skal testes, hvem som er målgruppen og at oppgavene er realistiske. Hvis ikke, vil de trekke dine konklusjoner i tvil etterpå.
En sann historie til skrekk og advarsel:
I en brukertest gjennomført at meg og en annen erfaren brukervennlighetsekspert hadde vi med produkteier for å bistå som observatør. Vårt formål var å teste om nye søk og filtreringsmuligheter ville gjøre det enklere for bruker å finne frem til varer i ulike kategorier. Mens to av oss til vår store frustrasjon observerte at brukerne ikke klarte å finne en naturlig strategi for å finne fram fordi vi hadde laget for mange muligheter i brukergrensesnittet så var produkteier lykkelig – hun hadde observert at folk snublet over ting de ikke var på jakt etter og anså det som en fin feature som ville føre til flere sidevisninger og økt respons…
Så galt kan det gå og det skyldes utelukkende misoppfatninger om testens formål. Ved å ta med produkteier i utarbeidelse av testplanen ville ulikt syn på formålet med endringene i systemet blitt avklart på forhånd, lenge før brukerne fikk slippe til.
Slik briefer du observatørene
Når du kaller inn folk:
- Sørg for at de vet hvor de skal møte, og når. De må minst møte 15 minutter før testen starter og de må informeres om at de blir avvist om de kommer for sent.
- Sørg for at de vet hva de takker ja til. Brukertestobservasjon er ikke en forestilling, de må arbeide hele tiden med notater, og de må dele sine observasjoner.
- Sørg for at de selv er ansvarlige for å kalle inn en stedfortreder dersom de selv blir forhindret fra å stille
- Gi klar beskjed om at de må observere minst to tester. En observatør som kun observerer én test vil bli farget av om testen gikk bra eller dårlig. Det kan være vanskelig å overbevise en som har observert én dårlig test om at systemet er bra, hvis de 7 andre brukerne klarte alle oppgavene. (Takk til @elitatt for dette punktet)
- Pek ut én person som er hovedobservatør. Denne personen må observere samtlige testbrukere
Før testen starter:
- Observatørene skal være kjent med testplanen. Ikke regn med at de har med en kopi, ha en klar til dem. Hele testplanen er ikke nødvendig å dele ut i alle tilfeller, men observatørene skal ha dokumentasjon som minst inneholder oppgavene som skal utføres, timeplan og oversikt over brukerne.
- Sørg for at det finnes penner, papir og evt. observatørskjema i observatørrommet
- Avklar ansvarsfordeling mellom deg og hovedobservatør. Hvem er ansvarlig for å holde rede på scoring av oppgaver iht. testkriteriene? Andre ting som hovedobservatør kan ta ansvar for er innsamling av notater, ta kopier av testplan og observatørskjema, forfriskninger til andre observatører osv.
Regler for observatører
Det er mange ting en observatør bør forstå, og dersom det er vedkommendes første test er det på sin plass med en liten prat om hvordan testen skal gjennomføres (ikke anta at observatørene har lest alt du har skrevet i testplanen).
Uansett observatør og situasjon, sørg for at de minst forstår følgende:
- Ikke snakk under testen uten tillatelse fra testleder
- Ikke svar på direkte spørsmål fra brukeren
Et bra (engelsk) sett med skriftlige instrukser til observatører finnes her.
Det kan være at observatørene har ekstremt viktig informasjon, eller at de tror de har det og er nødt til å dele det med testleder underveis i testen. Dersom de ønsker kontakt med deg, avtal et signal slik at du på et passende tidspunkt kan avbryte testen og høre hva de vil. De må uansett henvende seg til deg og aldri direkte til brukeren, med mindre du som testleder gir tillatelse til det. Med observatører i samme rom kan de for eksempel rekke opp hånda. Dersom de sitter i rommet ved siden av kan SMS være et alternativ for å få din oppmerksomhet.
Opplæring i notering
To hovedregler skal følges:
- Notere hva brukeren gjør, anta ikke hennes intensjoner
- Sitér brukeren nøyaktig, ikke skriv om
Det er viktig at observatørene noterer riktig slik at de i etterkant ikke trekker feil konklusjoner om hva de har observert. De skal kun notere faktiske hendelser og sitere bruker så nøyaktig som mulig.
Riktig:
Fritekstsøk ”hund og katt”, får 0 treff. Ser lenge på siden uten å klikke på noe før han spør ”Hvorfor er det så få treff her?
Feil:
Bruker får veldig få treff og skjønner ikke hvorfor basen ikke gir alle resultater, burde ha skrevet ”hund OR katt” det ville løst problemet
Observasjonsskjema
Et observatørskjema er en fin metode for å styre notatene i riktig retning. En variant er å lage faste skjemaer som er tilpasset oppgaven, med avkrysningsbokser for hvilke funksjoner eller sider som bruker er innom. Dersom du tester søkefunksjon, lag felter der observatørene kan notere søkekriteriene til brukeren. Her er et generisk eksempel på et observatørskjema, komplett med instruksjoner til bruker osv. En annen måte å gjøre dette på er å lage notatark med skjermbilder av systemet du tester. Lag ett ark pr. skjermbilde og sett av plass nederst på arket til notater. Observatør kan tegne piler til de ulike delene av skjermbildene, sette kryss ved funksjonalitet som ble brukt osv. og slipper å skrive like mye.
Et generisk observatørskjema du kan laste ned og bruke finnes på nedlastingsiden for maler
Suksesskriterie for oppgaver
Observatørene må forklares hva som er kriteriene for fullførelse av oppgavene som bruker skal utføre. Dersom det er en skala (Lett, vanskelig, ikke fullført, osv) må det forklares hva slags kriterier som skal legges til grunn for score på de ulike oppgavene. Dersom det skal noteres tider for start/stopp av oppgavene, må du bli enig om formatet (f.eks 02:50, ikke “ca 2 min”)
Involvering av observatører i testrommet
Før testen kan det være hyggelig å ta med brukeren innom observatørrommet for å si hei. Det er i min erfaring mindre skummelt for brukeren når han vet hvem som sitter på andre siden av glassveggen.
Dersom observatørene sitter i samme rom, sørg for at de sitter langt unna deg og testbruker. Plassér observatørene slik at det ikke er naturlig for bruker å henvende seg direkte til dem. Før testen starter lar du bruker hilse på observatørene og forklarer kort deres rolle. Husk å fortelle at de ikke skal si noe før etter at testen er ferdig slik at bruker ikke henvender seg direkte til dem under testen.
Etter endt test, før du avslutter med brukeren, spør observatørene om de har spørsmål til brukeren. Det har de nesten alltid. Det kan være klargjøring av observasjoner, ting de er nysgjerrige på osv. Sitter alle i samme rom, må du være svært tydelig på når du er ferdig med dine spørsmål og observatørene kan slippe til. Vær ordstyrer, og sørg for at diskusjonen avsluttes før testen går på overtid.
Debrifing – synkronisering av observasjoner
Ofte blir det satt opp en timeplan uten skikkelige pauser. I min erfaring gir det bedre resultater dersom du setter av minst en halv time mellom hver bruker, og at du bruker den tiden til å gjennomgå og ”synkronisere” notater med observatørene. Som testleder må du gå gjennom testoppgavene punkt for punkt og sammenligne notater. Observatørene vil få en større forståelse for sine observasjoner og du får samlet sammen og notert informasjon som de kanskje ikke har hatt tid til å skrive ned.
Dersom du hopper over denne debrifingen mellom hver bruker vil du risikere at observatørene har en annen oppfatning av hva som faktisk skjedde og du kan banne på at de i etterkant vil bestride dine påstander om systemets brukskvalitet.
Husk også å samle inn alle observatørene sine notater og skjemaer. Det er du som testleder som er ansvarlig for rapporten og til det trenger du alle observatørenes notater.
Kort oppsummert
- Book viktige folk tidlig
- Sørg for at dere på forhånd er enige om regler
- Ha en felles strategi for notering av observasjoner og scoring av oppgaver
- Bruk observatørskjema
- Slipp observatørene til på slutten
- Foreta en debrifing etter hver test for å synkronisere notater og score på oppgaver
Sist men ikke minst – enhver brukertest går bedre med sukker. Husk Bamsemums til både deg selv og observatørene, men servér brukeren først.
January 26th, 2010 at 14:29
Veldig nyttige tips Jon Gunnar!
Jeg må nok innrømme at jeg ikke er så flink til å verken disiplinere observatørene mht. snakking underveis eller til å gi de konkrete oppgaver i forhold til å registrere sine egne observasjoner.
Jeg prøver så godt det lar seg gjøre å få inn 10 minutters debrief mellom hver testdeltaker for å oppsummere hva som skjedde, men det hender at det er vanskelig å få til dersom det skjer noe som gjør at det blir tett mellom deltakerne.
Jeg har imidlertid som prinsipp at observatørene ikke kommer i kontakt med deltakerne direkte (se her for mitt synspunkt på akkurat det: http://bit.ly/8Btiv5). Det har skjedd at resepsjonisten har trodd at en deltaker er observatør og tatt vedkommende inn i observasjonsrommet. Det er i og for seg ikke noe galt med å se det, men jeg tror at det er mer stressende å tenke på at det sitter kanskje 5-6 personer og ser på enn at det sitter kun 1 person i rommet ved siden av.
Så mitt tips er å prøve å unngå å blande deltakere og observatører.
Jeg synes ofte at diskusjonen med observatørene underveis kan være fruktbar. Man har jo mulighet for å gå tilbake å se video på nytt i de delene man eventuelt går glipp av.
Jaja, kanskje jeg skal prøve å få observatørene til å gjøre et arbeidsslag mens de likevel er der
January 26th, 2010 at 15:21
Å unngå at bruker og observatør møter hverandre er dessverre umulig om du ikke har lab med separat observatørrom
Jeg opplever ikke at det tilfører testen veldig mye verdi å slippe til spørsmål fra observatørene, men jeg liker ikke å nekte dem heller. Ofte er det deres eneste møte med en faktisk bruker av produktet sitt.
Men man må passe seg for at de ikke spør om for mye. Når de begynner å spørre brukeren om dennes mening om X og Y, så vil de begynne å basere sine meninger på disse uttalelsene og ikke på observasjone fra testen som er langt viktigere. (Se på hva de gjør, ikke hør på hva de sier osv.) Som testledere er vi trenet til å vite forskjell på mening og handling men man kan ikke forvente at observatørene er det.
I praksis har jeg alltid en sidekick med i testene som er “hovedobservatør”, eller datalogger om man vil. Denne personen setter jeg alltid som ansvarlig for å logge fullførelse av oppgaver, evt. tidtagning osv. Det er også denne personens observasjonsnotater jeg legger mest vekt på når saken krever at notatene gjennomgåes. Ved bruk av Morae er det hovedobservatør som logger hendelser og skriver sitater i Morae observer.
Men sett gjerne observatørene i arbeid! Personlig liker jeg godt at de får innblikk i testscriptet eller at de får egne skjema spesielt laget for dem. Jeg ber også om å få innlevert notatene etterpå og sjekker gjennom dem for å sammenligne observasjoner.
January 27th, 2010 at 09:58
Flott artikkel, Jon! Du har fått med deg mange viktige momenter, ikke minst det å få med deg beslutningstakere.
Apropos det: Jeg har opplevd at beslutningstakere ikke kjøper konklusjonen min dersom resultatene fra testen spriker. Vi designere utvikler en teft om hva som kommer til å fungere, men vi har ikke bevis for det. Hva ville du gjort i en slik situasjon?
January 27th, 2010 at 10:37
Jeg har lab med separat observatørrom og lydtett vegg
Det største problemet jeg ser ved at observatørene (kunden) spør brukerne direkte er at det skal så lite til før brukeren blir ledet i en eller annen retning.
For eksempel å unngå at man bruker triggerord i spørsmålsstilling er noe som krever litt trening – det samme med å stille nøytrale spørsmål som ikke styrer brukeren dit man “vil” (bevisst eller ubevisst).
“Synes du ikke at det var bra?” eller “hvorfor plundret du så mye med å finne knappen?” eller “så du ikke at du kan velge i dropdownmenyen?”.
Opplever også (som du også nevner) at observatører er veldig fokusert på brukerens meninger, mens vi er opptatt av selve handlingene.
Når det gjelder testscript pleier jeg å ha en felles workshop med kunden eller oversende utkast på forhånd som skal godkjennes. Dermed er vi iallfall enige om hva som skal testes. Jeg har også laget dette som et utskriftsvennlig dokument hvor det er satt av plass til å skrive (håndskrevne) notater på, men har aldri bedt om å få notatene observatørene skriver innlevert til meg etter testen.
Kanskje vi burde ta en liten runde med bedriftsbesøk for å dele erfaringer og se på laboppsett? Vi er jo alle opptatt av å få inn best mulig testresultater
January 27th, 2010 at 11:18
@Haakon
Vi er nok redd for samme ting, det er riktig som du sier at det er skummelt å slippe løs utrente folk på brukeren, de vil stille ledende spørsmål og ta brukers svar for god fisk.
Vi har dessverre ikke egen lab men Ram vil vel snart få tilgang på én der han sitter? Jeg vil gjerne dele erfaringer om det.
@Ram
Det høres ut som en lignende situasjon som jeg nevner i blogposten. Er det uenighet rundt formålet med det systemet som er utviklet for å gjøre eller formålet med testen er uklart, eller om oppgavene er dekkende kan det oppstå uenigheter. Bare godt forarbeid vil kunne rydde opp i det.
Dersom testen faktisk viser at 3 klarte oppgaven og 3 klarte den ikke så kanman vel heller ikke konkludere. Da er vi over på mitt ord mot ditt problematikk. Jeg spurte vår felles sjef om slike problemstillinger for mange år siden (svaret regner jeg med var gjennomtenkt ettersom han tok seg betalt for det). Han sa: “Bare fortsett å argumentere. De andre vil gå tom for argumenter før deg, fordi du vet hva du snakker om og det gjør ikke dem”
Det er noe i det. Selv om du ikke har ryggdekning fra soleklare testresultater, så fortsett å argumentere – vi baserer ikke våre råd og designforslag på synsing, men på en kombinasjon av beste praksis og årelang erfaring. Be strong
January 29th, 2010 at 09:54
Kjenner meg igjen i mange av problemstillingene her
Veldig mange bra tips her!
Vi har ikke observatørene i samme rom. Laura Arlov har vært en forkjemper for dette og vet at Laura er veldig flink til å skape stemningen “Det er brukeren som er sjefen her, dere er her for å lære, ikke for å formane”. Tror kanskje det kan funke hvis det er et ekspertsystem og testdeltakeren føler seg som eksperten. Men, er det en åpen tjeneste og vi har inne deltakere som er helt fremmede for nettstedet som skal testes så foretrekker vi å tone ned dette med at det finnes observatører. Rett og slett for at testdeltakeren skal slappe av og ikke ha et bilde i hodet av dem som sitter på bakrommet. Vi informerer selvsagt alltid om at det sitter noen og “ser det samme som vi ser på skjermen her pluss et oversiktsbilde av rommet”.
I noen tilfeller har vi prøvd å introdusere observatørene, men erfaringen med dette er mest negativ. Til tross for formaninger har det kommet både unnskyldninger for hvorfor nettsidene er som de er og “vi visste det meste av dette fra før” pluss andre innspill som 1) brukerne ikke bryr seg om 2) brukerne helst ikke vil høre noe om.
Min erfaring er at brukerne ser ut til å glemme at noen observerer veldig fort og forholder seg til moderator.
Ang. spørsmål fra observatorer. Vi har prøvd Skype/SMS o.l til moderator, men det blir som regel bare mas på bakrommet om dette hvis man åpner for at observatorene også kan gjøre det. Sender melding til moderator, bare hvis det er slik at han/hun åpenbart misforstår noe som er viktig for testen.
På bakrommet varierer det veldig hva vi gjør av aktiviteter. Det kommer an på type test, type kunde og type observatorer. Ofte er det jo viktige diskusjoner på bakrommet, men blir dette for omfattende blir det vanskelig for vår observator å konsentrere seg om å tolke resultatene. Er det en prototype i et utviklingsløp med strenge tidsrammer så hender det at vi hiver problemene opp på veggen underveis og løser de nærmest der og da. I andre tilfeller er den mer formelle dokumentasjonen (rapporten skal f.eks distribueres til mange som ikke har vært med på testen) viktig og da er det viktig å dokumentere nøyere underveis.
Vi har kjørt Morae i flere varianter opp gjennom tidene, men bruker det mest til opptak av skjerm og ikke til å logge resultater. Her har vi prøvd mye forskjellig. Div. Excel løsninger som Datalogger: http://www.userfocus.co.uk/resources/datalogger.html , egenproduserte Excelmaler, MindMap m.m. Folk hos oss foretrekker ulike verktøy. Personlig har jeg havnet tilbake på gode gamle word
Vi bruker sjelden notater fra kundens observatorer. Å være en god observator handler vel så mye om å tolke det som skjer som å notere ned de kalde fakta. Dette krever erfaring og kompetanse innen brukskvalitet/interaksjonsdesign etc., noe som man ikke kan forvente at kunden innehar. Men, dette varierer selvsagt fra kunde til kunde.
Stikk gjerne innom for å kikke på labbene våre i Storgata 2 hvis dere ønsker!
January 29th, 2010 at 14:22
Jeg har etterhvert fått være med brukertester arrangert av flere leverandører og snakket med observatører fra flere selskaper. Det er absolutt forskjellige måter å gjøre dette på. Lurer på om vi skal arrangere et medlemsmøte i Dataforeningen der vi i fellesskap går gjennom hvordan man kan kjøre brukertester. Hovedhensikten må være å dele erfaringer — ikke fortelle “den ene rette veien” å kjøre brukertester. Jeg tror mange vil være interesserte i dette. Hva tror dere?
January 29th, 2010 at 21:13
Nå snakker vi. BITS frokostseminar om brukertesting? Melder meg frivillig til å holde et innlegg. Kan vi fly ned Ole for å fortelle om lab’en på NTNU?