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.

I motsetning til informasjonsnettsider og webshops er fagsystemer vanskelige å evaluere. Men slike fagsystemer er ofte ryggraden i en virksomhet og brukere er avhengige av det for å gjøre jobben sin. Derfor er arbeid med brukervennlighet desto viktigere men pga alle vanskelighetene, og at det er vanskelig å dokumentere en økonomisk gevinst ved å øke brukskvaliteten forblir de ofte tungvinte og vanskelige å bruke.

Løsningen kan være like enkel som den er genial – for å få en kontinuerlig strøm av feedback til systemeier, prosjektleder eller leverandør kan brukerdagbøker være løsningen. Kort fortalt går det ut på at utvalgte brukere (ikke ulikt et brukerpanel) fører en logg over hva de gjør i systemet. Når slike rapporter sendes inn regelmessig vil det danne seg mønstre over hva systemet brukes til, og man vil kunne se hvor folk får problemer osv.

En variant som ville gjøre det enda enklere er at man utstyrer alle superbrukere med en dagbok der de kan føre en logg over alle henvendelser de får fra sine kollegaer. Ja nemlig! Tenk om du i dette øyeblikk satt med en liste over samtlige ting noen har spurt en superbruker om det siste året. I ditt arbeid med brukervennlighet vil du få vite hvem du skal snakke med, hva de har problemer med, hvor hyppig problemer oppstår, hva slags mål brukerne har og hva slags oppgaver de utfører som gir dem vanskeligheter. Dessuten har du ikke løftet en finger for å få det til, og det er helt gratis. For godt til å være sant? Hvem vet, for jeg har ikke forsøkt det tidligere. Har du?

Metoden er enkel:

1. La brukeren teste flere designløsninger
2. Lag kort som illustrerer designløsningene og ha dem tilgjengelig under det påfølgende intervjuet
3. La brukeren sortere kortene etter preferanse

Metoden er basert på over tre års forskning ved brukbarhetslaboratoriet ved Norsk senter for elektronisk pasientjournal og er oppsummert i denne artikkelen

La brukeren teste flere designløsninger

I dag er det vanlig å teste en løsning. Brukerene tenker høyt, men de glemmer hva de har testet og greier ikke å sette sine erfaringer i et større perspektiv. Ved å la brukeren teste flere varianter av samme designløsning oppnår du en rekke fordeler:

• Du får testbrukerne til å sammenligne designløsningene opp mot hverandre.
• “Usynlige” brukervennlighetsproblemer åpenbarer seg for testbrukerne når de får prøvd en designløsning opp mot andre løsninger.
• Du får testbrukeren til å reflektere mer over muligheter og begrensninger i designløsningene
• Du sørger for god utnyttelse av testbrukerne siden hver testbruker evaluerer flere løsninger.

Lag kort som illustrerer designløsningene og ha dem tilgjengelig under det påfølgende intervjuet

Ved å lage illustrerende kort gjør du det langt enklere for deg selv og testbrukeren. Kortene må tydeliggjøre forskjellene mellom designløsningene. Fordelene er flere:

• Det er enklere for testbrukeren å huske forskjellen på alle designløsningene hun nettopp har prøvd. “Knowledge in the world rather than knowledge in the head”
• Det er enklere for brukeren å referere til de ulike problemene for det er bare å peke på kortene mens de forklarer problemet.
• Intervjuet blir mye mer fokusert fordi du som testleder kan henvise til kortene når kommentarene deres sklir ut.
• Du slipper å legge ord i munnen på brukeren fordi du kan si “hva synes du om denne [mens du peker på et kort]“
• Det blir rett og slett enklere for testbrukeren å reflektere over designløsningene de har brukt og du får langt mer tilbakemelding enn du får i vanlige brukertester.

La brukeren sortere kortene etter preferanse

Mot slutten av intervjuet ber du brukeren sortere kortene etter preferanse. Du ber de samtidig om å begrunne rekkefølgen. Med dette oppnår du en rekke fordeler:

• Du kan få bedre innsikt i hvilke designalternativer de foretrekker og hvilke de ikke foretrekker.
• Du kan lage statistikk av rekkefølgen og begrunne designbeslutninger med tall, noe sjefer elsker.
• Ved å be brukerne begrunne rekkefølgen får du dypere innsikt i hva som er viktigere faktorer for brukervennligheten.
• De viktige faktorene for brukervennligheten kan du bruke som evalueringskriterier i videre brukertester av produktet.

Hva er ulempene?

Metoden koster mer. Du må utvikle flere designvarianter, noe som kan ta noe tid hvis de er fundamentalt forskjellige. Men hvis forskjellene er små, behøver tiden og kostnaden ikke være avskrekkende. Selve brukertestingen tar noe mer tid per bruker, men utnyttelsen er mye større og honoraret trenger ikke øke proporsjonalt med den ekstra tiden.

Presentasjonen fra Yggdrasil finner du her:

[slideshare id=665034&doc=presentasjon-yggdrasil-2008-alsos-1224249696400035-8&w=425]

Bruker du en lignende metode?

En dansk studie av Jakob Otkjær Bak m. fl. som ble presentert på NordiCHI har forsøkt å finne svar på spørsmålene. I denne studien spurte de 39 danske organisasjonene om deres forståelse av brukertesting og om de benyttet metoden.

29 av de 39 organisasjonene hevdet at de brukte brukertesting. Men det viste seg at de fleste av disse missforstod hva en brukertest virkelig var og trodde det var det samme som det vi kaller funksjonstest. Andre organisasjoner trodde brukertest var det samme som å be om å få tilbakemeldinger fra kunden på en tidlig versjon av programmet som var sendt til dem. Andre arrangerte møter med kunden der de diskuterte brukervennlighetsproblemer i systemet. Bare noen ytterst få av de 39 organisasjonene gjennomførte det vi kaller brukertester (der brukere blir observert mens de gjennomførte oppgaver på et system). Det viste seg at brukertesting er en lite utbredt metode.

Så hva er det som forhindrer brukertesting?

Dybdeintervjuet avslørte at utviklernes holdning til brukertesting og begrensede ressurser var de største hindrene. I tillegg viste det seg at mange hadde feil oppfatning om hva brukertesting virkelig var, og trodde at det var det samme som funksjonstesting.

Tidligere har andre funnet ut at…

• rigide utviklingsprosesser og -metoder lager hindrer for brukertesting,
• brukerinvolvering gjør programmering vanskeligere og forlenger utviklingsprosessen,
• brukertestingen skjer for sent i utviklingen

Det finnes også studier som kan tyde på at de som jobber med brukervennligheten…

• ikke klarer å bli integrert i utviklingsprosessen,
• ikke kjenner brukerene godt nok,
• ikke har god nok kompetanse,
• ikke blir respektert på grunn av sin unge alder.

En tredje gruppe hindringer handler om at utviklere…

• ikke har kompetanse til å selge brukervennlighet i organisasjonen
• ikke forstår kompleksiteten i design av brukervennlighet

Andre hevder at programvareleverandørene ikke vil lage første versjon av systemet brukervennlig. På denne måten kan de tjene penger på å selge en versjon 2 (eller 3) av systemet der brukervennlighetsproblemer er fikset.

Hva skal til for at organisasjoner faktisk brukertester systemene sine? Har dere noen erfaringer?

Den såkalte think-aloud-protokollen er svært ofte benyttet under brukbarhetstester. Det er en teknikk der brukeren blir bedt om å tenke høyt, det vil si beskrive med egne ord hva hun gjør, hva hun forventer av systemrespons, og hvilke problemer hun opplever.

I tre ulike brukertester i har vi funnet ut at problemet med denne teknikken oppstår når brukeren må forholde seg til andre personer. Da opplever vi at testpersonene rett og slett glemmer å tenke høyt. Dessuten, i de tilfellene hvor de husker det, reduseres realismen.

Alle tre brukertestene her hentet fra en sykehussetting der helsepersonell bruker et mobilt system under en pasientvisitt. Resultatene er hentet fra en artikkel jeg og Yngve Dahl har publisert i NordiCHI 2008. Du finner mer detaljer om studiene og mer utdypende informasjon der.

Den første brukertesten testet vi et kontekstsensitivt system som automatisk fant frem pasientopplysninger når legen nærmet seg pasienten. Vi plasserte pasienter i sengene og instruerte brukeren til å tenke høyt under bruken av systemet. Under disse testene observerte vi at think-aloud ble bare delvis benyttet av deltakerne. Fokuset lå på pasientdialogen, ikke dialogen med testlederen.

I den andre brukertesten testet vi et system som lot brukeren finne røntgenbilder på en PDA og deretter vise dem på en pasientterminal som var montert på pasientens seng. Her ble think-aloud instruert, men bare unntaksvis benyttet av testdeltakerne. I denne testen var dialogen med pasienten i større fokus enn i den forrige testen.

I den tredje testen testet vi et mobilt medikasjonssystem som lot legene endre medisineringen eller legge til nye medikamenter ved pasientens seng . Basert på erfaringene fra de to foregående testene instruerte vi ikke think-aloud. I denne testen opplevde vi bedre pasientdialog og økt realisme.

Med fare for å overgeneralisere: Helsepersonellet ikke er i stand til å holde to dialoger i gang; en med brukertestleder og en med pasienten. Dessuten ble testene utført i omgivelser som i stor grad lignet deres normale arbeidsomgivelser. Det gjorde at testbrukerne var ”på jobb”, noe som gjorde at de helt glemte testlederen. Når man brukertester systemer der brukerne må forholde seg til andre personer, kan man ikke forvente at de klarer å tenke høyt i tillegg.

Men hvordan fikk vi innsikt i hva brukerne tenkte under testen? Det finner du i dette blogginnlegget.

Referanser:

• Alsos, O. A. (2005). Exploring interface metaphors for using handhelds and PCs together, NTNU.
• Alsos, O. A. and D. Svanaes (2006). Interaction techniques for using handhelds and PCs together in a clinical setting. NordiCHI.
• Dahl, Y. and D. Svanæs (2007). A comparison of location and token-based interaction techniques for point-of- care access to medical information. Personal and Ubiquitous Computing.
• Dabelow, B. (2008). Reducing Attention Theft – New interfaces for the mobile electronic patient pecord, NTNU.
• Alsos, O. A. (2008). Attention and usability issues in mobile health information systems at point-of-care. Stud Health Technol Inform 136: 877-8.

”Vil du ha prim eller brunost?”
- Få mer ut av brukertestingen med barnepsykologi!

I stedet for å spørre to-åringen hva hun vil ha på brødskiven, gjør du det lettere både for deg og henne hvis du heller tilbyr flere alternativer og lar henne velge selv. En tilsvarende fremgangsmåte overfor testbrukere kan motivere dem til å reflektere i større grad rundt designløsningene du vil brukerteste.

Som testleder er du avhengig av at brukeren er i stand til å sette ord på sine erfaringer under brukertesten for å få avdekket brukbarhetsproblemer. Men brukere glemmer ofte å tenke høyt under testen. Dessuten er det ikke alltid like lett å få dem til å reflektere over løsningen de nettopp har prøvd.

Foredraget beskriver i detalj en metode vi har utviklet for å få brukerne til å reflektere i større grad over designløsningene de tester. Metoden går i svært korte trekk ut på å la dem teste flere ulike designløsninger samt å benytte en teknikk under det etterfølgende intervjuet som vi kaller card ranking. Teknikken hjelper brukerne å reflektere over designløsningene ved hjelp av illustrerende kort.

Resultatene våre viser blant annet at…

• potensielle problemer med en designløsning er ikke alltid like tydelig for brukeren,
• uttesting av flere forskjellige designløsninger gjør det lettere for brukeren å reflektere over brukbarhetsproblemer
• card ranking gjør det lettere for brukeren å huske og skille mellom løsningene de har prøvd,
• at kortene gjør det enklere for brukeren å peke på brukbarhetsproblemer,
• at kortene gjør det lettere for testlederen å holde fokus under intervjuet,
• at metoden ”produserer” mer tilbakemelding fra brukeren,
• at metoden avdekker flere brukbarhetsproblemer,
• at metoden passer best i en tidlig fase av utviklingsprosessen,
• at metoden også har noen svakheter (som vil bli diskutert nærmere).

Metoden er et resultat av fem års forskning og erfaring fra brukertesting av eksperimentelle og kommersielle systemer. Metoden er utviklet ved NTNU i et av verdens mest avanserte brukbarhetslaboratorium. I foredraget vil vi beskrive metoden, hvorfor den fungerer og hvordan praktikere enkelt kan ta den i bruk.

Resultatene fra denne forskningsstudien blir publisert i NordiCHI 2008 i Lund i Sverige.

Når man tester skrivebordsapplikasjoner og nettsider holder det med et enkelt kameraoppsett og speiling av skjerminteraksjonen. Integrerte mikrofoner og webkameraer sammen med et brukertestingssystem som for eksempel Morae holder i massevis.

Hvis man derimot skal teste mobile systemer oppstår helt nye utfordringer. Noen løser dette med å be brukeren holde mobilen i et visst område som er dekket av kameraet. Problemet at det hindrer brukeren i å være mobil.

Andre monterer trådløse minikameraer på den mobile enheten. Det gjør den mobile enheten større og tyngre, og gjør at brukeren ikke kan plassere den i lommen når den ikke er i bruk. Felles for disse teknikkene er at de lett kan påvirke den oppfattede brukervennligheten av designet eller redusere gyldigheten av resultatene fra brukertesten.

For å oppnå gyldige brukertestresultater er det viktig at opptaksteknikkene ikke påvirker måten testpersonen bruker den mobile enheten, samtidig som at de gir nok data. Vår metode består av opptak på tre nivåer:

• Speiling av den mobile enheten: Det gir oss brukerens interaksjon med det grafiske brukergrensesnittet
• Styrbart tak-montert kamera: Ved å zoome inn på den mobile enheten får vi bilder av interaksjonen med selve dingsen; hvordan brukeren behandler den, hvilke fysiske knapper hun trykker på.
• Styrbar tak-montert kamera eller vanlig kamera: Det gir oss bilder av brukerens interaksjon med omgivelsene, for å sette bruken av systemet i en større kontekst.

I tillegg har vi forsøkt ulike teknikker for å få testpersonenes synsvinkel. Vi har forsøkt med mobilt øyesporingsutstyr for mobile brukere (som blir et senere blogginnlegg) og trådløst minikamera i hodehøyde for stasjonære brukere.

Vi har brukt opptaksteknikkene i en serie brukertester av mobile applikasjoner for sykehuspersonell. Under disse testene opplevde vi at legene stadig bevegde seg rundt i rommet med den mobile enheten og plasserte i lommen mens de ikke brukte den. Det viser hvordan opptaksteknikker som involverer vanlige, fastmonterte kameraer eller trådløse minikameraer kan påvirke bruksmåten.