Dette er en enkel instruksjonsvideo som viser de mest grunnleggende trinnene i det å planlegge en brukertest.

For tilgjengelighetens skyld er filmscriptet gjengitt her:

Stein på stein – hvorfor rekkefølgen av tingene som må planlegges er viktig

1. Hva er formålet med brukertesten?
Er det å skaffe innsikt i faktisk bruk, eller vil vi vite om systemet er lett å lære for nye brukere? Det er viktig at formålet med testen er forankret hos alle beslutningstagere.

2. Hvilken funksjonalitet skal testes?
Vi kan ikke teste alt. Ut fra hvilket formål vi har med testen, må vi bestemme hvilke funksjoner i systemet som skal testes.

3. Hva slags system skal du teste på?
Hvor er den funksjonaliteten som skal testes tilgjengelig? Er det en spesiell versjon av systemet, er det test eller produksjonsdata, eller kanskje en prototype?

4. Hva slags brukere skal få komme og teste?
Hvem er den funksjonalitet som skal testes tiltenkt? Definér målgruppen og andre kriterier for utvelgelse av brukere, og hvor du skal få tak i dem.

5. Hva slags testutstyr skal brukerne benytte?
For å gjøre testen så realistisk som mulig for målgruppen må du gjenskape faktisk bruk. Det er ikke sikkert alle har en 24-tommer skjerm og bredbånd slik som du har.

6. Hvilke oppgaver skal brukerne få?
Lag realistiske oppgaver som dekker den funksjonaliteten som skal testes. Du må også definere hva som er sukesskriteriene for disse oppgavene.

Som du ser er planlegging en sekvensiell prosess. Valgene du tar underveis påvirker de neste og hjelper deg å holde fokus. Dersom det ikke er tydelig hva formålet med testen er, vil du ha store vanskeligheter med å beslutte de neste trinnene.

Slik planlegger vi en brukertest. Lykke til.

Som systemeier ønsker man å vite hva som er de mest vellykkede og de mest problematiske funksjonene til et system i forhold til oppgavene det er tenkt å løse:

• Hjelper systemet den tiltenkte målgruppen?
• Hva slags problemer har brukerne?
• Hvem bruker egentlig systemet?
• Hvorfor blir ikke systemet brukt slik vi ønsker?
• Hva slags spørsmål får superbrukerne våre?
• Hva kan gjøres for å korte ned opplæringen?
• Finnes det funksjonalitet som ikke brukes og kan fjernes?
• Har vi nådd målene for effektivitet/brukskvalitet/saksbehandlingstid?
• Kan innspill fra brukerne systematiseres på noen måte?

Vanligvis har den forutseende systemeier sørget for at viktige metrikker logges når systemet brukes. Men logganalyser kan bare fortelle deg halve historien – dvs. du ser hva som blir brukt, men aldri hvordan eller hvorfor. Med undersøkelser som brukerintervjuer og brukertester får du innsikt i hvilke områder av systemet som trenger forbedring. Da kan du bruke forvaltningsbudsjettet på å videreutvikle det som er viktig for at systemet forblir en suksess.

Brukerintervjuer med representanter fra målgruppen er en enkel og positiv måte å få innsikt i hvordan systemet ble mottatt og hva brukerne sliter med og de setter pris på å få dele sine erfaringer.

Brukertester gir stor innsikt i hvordan systemet egentlig brukes og kan for de som observerer for første gang bli en åpenbaring. Innsikten gjør at man enklere kan prioritere hva som skal utvikles.

Brukerdagbøker systematiserer tilbakemeldingene fra brukerne. Man kan velge ut enkelte brukere som fører dagbok over sin bruk av systemet, eller man kan be superbrukerne skrive en logg over alle spørsmål de får – når informasjonen er samlet inn og systematisert har du et godt bilde av hva brukerne trenger.

Konklusjon
Forvaltning er mer enn bare oppetid, det handler også om å forvalte brukeropplevelsen. Hvordan vet du hvilken funksjonalitet som er mest brukt, hvilken funksjonalitet folk sliter med og hva du kan fjerne? La brukerne medvirke slik at forvaltningsbudsjettet kommer dem til gode.

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?

På Flybussen sine sider blir jeg møtt av blide ansikter-  hele 10 tilsammen og mange er animerte. Søkefeltet som drukner i dette visuellet orgiet av ansikter er også et syn for seg. Under de 10px store dropdown-kontrollene finnes en vannrett gradestokk av enorme dimensjoner. Er det 11 grader kvikksølvet viser?

Nei, det er en slider for å velge klokkeslett. Og hvor er søkeknappen? Så grundig som dette er det sjelden jeg står fast på noe nettsted. Jeg VET at det går en buss til og fra Sonsveien, men Son er ikke noe sted å finne. Så i dette skjemaet velger jeg som følger:

Se så. Der kom det et resultat, det bare skled ned fra den hengepuppen som tidligere ble vist under gradestokken. I listen vises alle ruter på valgte tidspunkt (ca 16 grader) fra Gardermoen – til gardermoen, med reisetid på 0 minutter. Fantastisk! Dropdown-kontrollen “til flyplass” lar deg i steden velge “fra flyplass”. Det gjorde jeg, i den tro at jeg fikk se avganger fra Gardermoen når det var ca. 16 grader. Den gang ei, da fikk jeg samme resultat en gang til. Stedslisten viser bare de store byene så jeg har nå forstått av flybussen.no er en merkevare som ikke favner alle busser som går fra Gardermoen. Litt googling avslører at det er Flybussekspressen som går til Son. Men nå er jeg nysgjerrig på hva slags tilbud flybussen.no har og leter videre for å se hva mer flybussen.no har å tilby.

Du kommer hvertfall ikke frem med flybussen.no
Du er ikke fremme før du er fremme, skryter de på sine nettsider. Denne noe kryptiske påstand underbygges av deres nye nettløsning, lansert 29. september i fjor iflg. nevnte nettside. Siden som informerer om lanseringen nevner bl.a.:

“Hurtigsøket gir deg anledning til å finne rutetider for Flybussen med noen få tastetrykk”

Hva slags hurtighet de har målt det til vites ikke, erfaring fra brukertester viser at dropdown-kontrollere er notorisk vanskelige å bruke og dersom du måler antall klikk, så er de noe av det mest klikk-krevende jeg vet om. Dessuten foregår hurtigsøket HELT uten tastetrykk.

“Sist men ikke minst, har du også mulighet til å bruke vår karttjeneste. Denne finner du øverst til høyre på hver enkelt avdeling sin underside. Dersom du skal på et møte kan du skrive inn adressen, så vil vi vise deg hvilke holdeplasser som er nærmest. Du kan også planlegge hvilken bussavgang du skal benytte med kartløsningen”

Dette høres nyttig ut. Men si meg en ting,  hvor er “øverst til høyre på hver enkelt avdeling sin underside” om jeg tør spørre? Jeg ser et grønt kart på forsiden, det kalles “detaljert søk” og gjør følgende: Du kan velge et sted, og deretter får du det samme skjema som for hurtigsøk, men da kun for det stedet du valgte i kartet.

Er det pinlig nok, eller skal jeg fortsette?
Jeg kunne latt godt nok få være godt nok og slippe flybussen.no ut av gapestokken. Jeg er tross alt ikke ond, så jeg kunne vendt det andre kinnet til som vanlig. Men det var helt til jeg klikket på en link og oppdaget at den åpnet samme side, men da inne i et frameset:

Det var dråpen. Nå er det fengselsregler som gjelder. Flybussen, kjære snille Flybussen, fortell meg hvorfor dere lar meg oppleve alt dette, i 2009:

Tomme sider
Menyvalget “Flybussene i Norge” inneholder kun et gigantisk banner med reklame for Flybussen, med teksten “Du er ikke fremme før du er fremme”

Elendig informasjonsarkitektur
“Kontakt” og “selskapene” i hovedmenyen er samme ting, men splittet opp og ikke linket mellom hverandre. Det finnes også en tredje side som heter “kontaktinfo”. Se om du klarer å finne den, den har nemlig et annet innhold…

STORE BOKSTAVER og floskler
I venstremenyen, som jeg ikke helt har forstått hvor og når dukker opp, BRUKES UTELUKKENDE STORE BOKSTAVER. Se f.eks. menyvalget “BEFORDRINGSVEDTEKTER” som ikke har noe innhold, men som henviser til et sted (ikke linket) hvor disse kan leses.

Under menypunktet “VELKOMMEN TIL VÅRE NYE NETTSIDER” finner man enda mer informasjon om de tidligere omtalte “web sidene” (overlagt ord delings feil, red. anm)

SAS Flybussen har sammen med flybusser i 14 norske byer etablert nye nettsider. Dette for at du som kunde skal oppleve våre sider som mer brukervennlig og informative.

Nei kjære dere, men jeg finner det hele svært interessant rent faglig… Tanken er god, men akk så brukerfiendtlig gjennomførst. Her er det de beste intensjoner om å skape gode opplevelser, de er til og med uttalt på nettstedet – Brukervennlige og informative skal de være. Så hva med å la brukerne medvirke neste gang? Se for øvrig mine 10 bud for gode brukeropplevelser.

Døde linker
Sist, men ikke minst: under “KJØP BUSSBILLETTEN PÅ NETT” kan man klikke på linken “Klikk her for kjøp” og få følgende beskjed:

“Siden er ute av drift.
Billetter kan kjøpes på bussen.”

Og med det får flybussen i Oslo siste ord i denne omgang.

1. Snakk med brukerne dine
Ved å bruke kvalitative undersøkelsesmetoder vil du få innsikt i brukernes behov og med din kunnskap om ditt marked og din teknologi vil du ha de beste forutsetninger for å skape gode brukeropplevelser.

2. Planlegg brukeropplevelsen
Det er enkelt å legge en plan for brukeropplevelsen. Bedrifter har ofte merkevarestrategier som inneholder stikkord for hva slags assosiasjoner de ønsker at brukerne skal ha til deres merkevare. Skal merkevaren oppleves som Moderne, Innovativ og Spennende? Bruk det som en rød tråd når du designer.

3. Ta ansvar for brukeropplevelsen
Brukeropplevelsen er summen av alle beslutninger om teknologi, implementasjon, utseende og interaksjon. Systemutviklere er ofte de som har størst påvirkning på brukeropplevelsen, men de er ofte ikke klar over det. Ethvert prosjekt må ha en beslutningstager som er ansvarlig for brukeropplevelsen og kan være brukerens advokat, sørge for motivasjon, inspirasjon og være ansvarlig for å ivareta den helhetlige visjonen.

4. La brukerne medvirke i prosjektet
Brukermedvirkning er en forutsetning for å lykkes med å skape gode brukeropplevelser. Ved å vise prototyper for faktiske sluttbrukere, gjennomføre brukervennlighetstester og planlegge for forandringer i prosjektet på grunnlag av slike undersøkelser vil du kvalitetssikre brukeropplevelsen på et tidlig tidspunkt slik at du kan lansere med minimal risiko.

5. Vær entusiastisk
Entusiasme smitter. Dersom prosjektdeltakerne er entusiastiske overfor produktet de lager, vil det vises. Løsninger som lages med lidenskap vil ofte holde høy brukskvalitet. Den som er ansvarlig for brukeropplevelsen må skape motivasjon og inspirasjon.

6. Vær konsekvent
Ukonsekvent oppførsel fra digitale produkter kan i verste fall oppleves som psykopatisk. Vær konsekvent med navigasjon, begreper, utseende og tekst.

7. Ha et passende tonefall
Språk, tekst og tilbakemeldinger er viktig. Ved å sørge for et omtenksomt, saklig og høflig tonefall som treffer din målgruppe unngår du at brukeropplevelsen blir upersonlig, tørr eller kjedelig.

8. Design omtenksomhet
Dersom brukerne skal like produktet ditt, må det oppføre seg som en omtenksom person. Databaser er notoriske til å legge ansvar for sin utilstrekkelighet over på brukeren så du må sørge for at alle deler av ditt system ”oppfører seg ordentlig”.

9. Mål brukeropplevelsen
Dersom det er verdt å lansere, er det verdt å måle. Empirisk grunnlag om faktisk bruk får du først etter lansering, men du må ta høyde for det underveis. Med webløsninger må du bygge inn støtte for webanalyse underveis for å få de svar du ønsker. Det er billigere enn å gjøre det i etterkant.

10. Gjør det for brukerne
Googles 1. bud slår fast at brukeren kommer først, ikke pengene. Det er egentlig ganske enkelt, sier journalist Jan Omdahl: ”Setter du brukeren i fokus, kommer inntektene etter. Setter du inntektene foran brukeropplevelsen, går brukerne et annet sted.”

Har du flere bud? Det finnes også andre mer manifest-lignende lister å finne på nettet, f.eks. Eric Reiss’ Web Dogma og Dieter Rams 10 commandments.

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?

Når jeg jobbet i FINN.no var det ofte behov for avsjekk med brukere underveis. Vi måtte ha svar der og da. I smidige prosjekter har man sjelden tid til omfattende brukertester og denne metoden ble brukt en del etter at vi så nytten av å vise det vi laget til folk – hvem som helst – og observere.

Ordet Gonzo er stjålet fra journalist og forfatter Hunter S. Thompson som praktiserte det han kalte Gonzojournalistikk, at man selv måtte oppleve det man skrev om. Det er dårlig business å være sin egen testbruker, men siden man oppsøker brukerne der de er fremfor å kalle dem inn syntes jeg dette var et passende navn.

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.