Hva gjør jeg etter brukertestene?
Er du designer, kjenner du deg sikkert igjen i denne situasjonen: Du eller ditt team har invitert brukere til å teste om løsningen dere har laget virker og gir mening — en såkalt BRUKERtest eller BRUKstest. Dere tar farvel med brukeren og puster lettet ut.
Men hva gjør dere nå for å ta vare på det dere har sett og hørt, slik at dere kan lære av det og lage en bedre løsning?
Som tjenestedesign-trainee i Fremtind har jeg fått være med på ulike brukertester og sett hva ulike designteam gjør med materialet etterpå.
Først en kjapp gjennomgang av hvorfor vi brukertester. Mot slutten av teksten kommer jeg litt inn på hva vi lærer av å brukerteste mye. Ved å ha en god plan for hvordan vi skal lære fra brukertester, legger vi til rette for å kunne gjennomføre flere brukertester og lære mer. Det er det denne teksten først og fremst handler om.
Hvorfor brukertester vi?
Vi designer en løsning med utgangspunkt i behov kundene våre, eller andre brukere, har. Vi lager noen hypoteser om hvordan vi kan hjelpe dem. For å finne ut om vi er på rett spor, lager vi prototyper som viser hvordan hele eller deler av den ferdige løsningen kan bli. Så lar vi ekte folk teste dem.
Noen ganger tester vi om konseptet gir mening (konsepttest). Andre ganger tester vi om løsningen er brukervennlig. Ved å lage konkrete prototyper gjør vi ideene våre om til noe håndfast det går an å teste og diskutere. Hva slags prototype vi tester gir noen føringer for hva vi gjør etterpå.
Målet er å lære hva som funker i den nye løsningen, og hva som ikke funker. Dermed forstår vi mer av den problemstillingen vi prøver å finne en løsning på. Da kan vi lage en ny versjon som forhåpentligvis treffer bedre.
Så, hva gjør vi etterpå?
Observatørene i en test noterer det brukerne sier og gjør, på en oversiktlig måte. Til en brukervennlighetstest har vi oppgaver for å teste om brukerne får til det vi forventer, med klare suksesskriterier. Vi kan bruke en observasjonstavle, digitalt eller fysisk, og denne kan være utformet som en matrise med oppgaver og brukere. Vi setter lapper inn på rett sted i matrisen og det blir lett å sammenligne hvordan de ulike brukerne.
I en konsepttest deler vi observasjonstavla inn i fire, merket med «Liker», «Kritikk», «Spørsmål» og «Ideer». Da får vi notert spørsmål og ideer som dukker opp når vi går gjennom observasjonene. Vi kan også lage en matrise med skjermbilder fra kundeløsningene, og sette lapper med observasjoner på hva brukeren gjør på hver side.
Vi bruker ulike farger på lappene slik at det blir lett å finne riktig informasjon.
- Blå for observasjon, rød og grønn for om brukeren klarte oppgaven eller ikke, hvit for foreløpige funn
eller
- ulike farger for ulike brukere eller observatører
eller
- noe annet som fungerer for din test
Det er viktig at vi har definert de ulike fargekodene, og at observatørene forstår hvilke fargekoder de skal bruke. Det er lurt at hver observatør noterer det de ser for seg selv, og at vi lager og sammenstiller lappene sammen. Da unngår vi duplisering og får diskutert ulike opplevelser av hva vi har sett. Her kan vi også ta en titt på eventuelle opptak vi har gjort av testen.
All registrering av hva brukerne sier og gjør skjer umiddelbart mens observasjonene friskest i minnet.
Det er også lurt å notere ned hva brukerne sier om det de gjør. Hvordan beskriver de det de interagerer med? Hvis de gjetter på hva de skal gjøre, kan ordene de bruker gi oss en pekepinn på hva de prøver å få til.
All registrering av hva brukerne sier og gjør skjer umiddelbart mens observasjonene friskest i minnet. Etter testene gjør vi en avsluttende oppsummering. Da er det lurt å prioritere de viktigste funnene sammen med observatørene. Det gjør det enklere å lage en oppsummering, formidle resultatene og ta tak i ting.
Analysere det vi har observert
Nå går vi i gang med neste steg, som er å analysere observasjonene våre. Hvordan vi gjør det, er avhengig av om vi tester konsept eller brukervennlighet.
Vi kan bruke metoden «å dele inspirerende brukerhistorier» ved begge typer tester — hvor observatørene forteller noe de syntes var interessant eller inspirerende med det de observerte. Ofte er det noe brukerne gjorde annerledes enn det vi trodde de ville gjøre. Mens én person forteller, skriver de andre ned punkter på post-it-lapper. Når alle har fortalt, setter vi lappene opp på veggen og grupperer dem for å få fram mønstre og temaer, og formulere funn.
— Konsepttest —
Vi gjør konsepttester for å finne ut om løsningen gir mening. Da tar vi utgangspunkt i hypotesene om hva kunden har behov for og hvordan vi kan tilfredsstille de behovene. Stemmer den bruken vi observerte i brukertestene med hva vi trodde brukerne kom til å gjøre? Hva fortalte de oss underveis som ga ny innsikt i problemene vi prøver å løse?
Noen ganger spør vi brukerne etter testen om hva de ville gjort annerledes. Da får vi sjelden svar vi kan bruke direkte. Svarene deres kan likevel fortelle oss om behov vi har oversett eller ikke greid å tilfredsstille tilstrekkelig. Som vi må finne nye løsninger på.
— Brukervennlighetstest —
Vi gjør brukervennlighetstester for å finne ut om brukerne får til å gjøre det de ønsker. Da har vi registrert hva som gikk galt underveis, og nå er vi interessert i å finne ut hvorfor. Da er det lurt å se på hvordan brukerne forsøkte å løse oppgavene. Hva var det de forventet å få til? Hvilke strategier brukte de?
Vi kan også se på hva brukerne lærer underveis. Fikk de til en oppgave mot slutten, som de ikke fikk til i starten? Det kan tyde på at de har lært logikken selv om den var fremmed til å begynne med. Noen ganger er løsningen så enkel som at en knapp må være mer synlig. Andre ganger, og særlig tidlig i prosessen, redesigner vi helt fordi logikken i løsningen ikke fungerer.
Oppsummere funn
Vi oppsummerer observasjonene våre og formulerer nøkkelfunn som forteller hva vi må tenke på videre i løsningen. I Fremtind gjør vi gjerne det i presentasjoner for teamet og beslutningstakere. Her tar vi med eksempler fra brukertestene, sitater fra brukerne, klipp fra opptak og annen innsikt som bygger opp under argumentasjonen. Vi tar også med foreløpige hypoteser om hvordan vi kan imøtekomme disse behovene og teste nye hypoteser.
Videre ser vi på hvor mange som ikke fikk til å løse oppgavene, og hvor ofte vi antar at dette vil gå galt. Dette er viktig å vite i iterasjonen.
Prioritere tiltak
For hvilke av disse problemene skal vi velge å løse? En brukertest vil som regel avdekke flere problemer enn vi har tid og mulighet til å gjøre noe med. Det er også et spørsmål om vi ved å løse et problem, forsterker et annet.
For å prioritere hvilke problemer vi skal ta tak i, kan vi plassere problemene inn i en 2x2-matrise. Denne kan settes opp for å vurdere hvilke løsninger som gir stor verdi for brukeren og som er lette å implementere, eller for å se hvilke problemer som vil påvirke mange brukere ofte, og som dermed bør prioriteres.
Konteksten har også noe å si for hvilke problemer vi velger å løse. Hvis man designer et internt system som man kan kurse folk i, trenger ikke alt være selvforklarende. Noe funksjonalitet brukes imidlertid sjeldent, og brukeren kan lett glemme hvordan hen bruker den fra gang til gang. Da bør disse funksjonene være selvforklarende allikevel. Hvis brukertesten viser at den ikke er det, kan det være at vi skal prioritere dette problemet, selv om det treffer sjeldent og få personer.
Resultat
For å få bedre resultater og for å få gjennomslag for avgjørelsene, er det viktig at det er en omforent analyse basert på reelle funn fra brukerne. Analysen bør ikke kunne avskrives som én designers mening eller synsing. Derfor er det en fordel om designerne ikke sitter alene med analysen og prioriteringene, men har med funksjonell arkitekt, produkteier eller andre relevante samarbeidspartnere.
Resultatet av analysen og prioriteringen bør være at vi har bestemt oss for hvilke problemer vi vil gjøre noe med og at vi har forstått mer av hvorfor det ikke gikk som vi trodde. Hvis vi har brukt testen til å få innspill på ulike versjoner (A/B-testing), må vi bestemme hvilken versjon vi skal gå videre med. Vi må sitte igjen med konkrete aksjonspunkter vi kan ta med oss inn i en ny iterasjon av løsningen, og vi må ha bestemt hvem som skal gjøre hva.
Så tar vi med oss den lærdommen vi har fått fra testene og går inn i en ny bygge-teste-lære-runde. Hvordan du gjør det, hører til i en annen tekst.
Hva lærer vi av å brukerteste mye?
I begynnelsen av artikkelen fortalte jeg om hvorfor vi brukertester en konkret løsning eller konsept. Det å brukerteste har imidlertid fordeler utover hva vi lærer om den umiddelbare problemstillingen. Vi forstår brukerne våre bedre når vi ser dem prøve å løse problemene sine, og det gir inspirasjon til å hjelpe dem å få til det de strever med. Det kan vi ta med oss til videre arbeid med løsningen. Dette er en av grunnene til at det er viktig å ha med hele teamet eller prosjektgruppa på i hvert fall noen av testene.
Å ha med andre teamdeltakere gjør også at brukertestene fungerer som lagbygging. Vi får samkjørt teamet og sørget for at alle har samme forståelse av det problemkomplekset vi prøver å løse sammen. Det bygger også en gradvis forståelse i organisasjonen for viktigheten av å møte brukernes behov, og gir tyngde til argumentene om å bruke tid og ressurser på de designaktivitetene som må til.
Design er et fag som bygges på mye bevisst kunnskap om brukere, brukssituasjoner og hvorfor ulike løsninger fungerer. I likhet med mange andre fag, er det imidlertid også en del av det vi kaller magefølelse, intuisjon eller taus kunnskap. Dette er det vi «vet» at stemmer, basert på erfaringen vi har med brukere og brukssituasjoner. Til syvende og sist kan dette bare læres gjennom prøving og feiling, og det får vi erfaring med gjennom å bygge prototyper og teste dem.
Organiserer vi etterarbeidet etter en brukertest godt, blir de mindre ressurskrevende å gjennomføre, og vi får mer ut av dem. Da er det også lettere å gjennomføre flere brukertester, oftere, og få bonuseffektene økt empati, inspirasjon og sterkere magefølelse. Det bestreber vi oss på å gjøre i Fremtind.
Kilder
— Samtaler med Kristine Sørensen, Ingeborg Wiulsrød, Eirik Fatland og Margrethe S. Johnsen.
— Arbeid sammen med Kristin Svendsen
— «Hvordan jobbe datadrevet?» Onepager av Kristin Svendsen og Jon Magnus Eiliertsen
— Interaction design foundation, 2022. Lesson 6.6. Test your prototypes: How to Gather Feedback and Maximize Learning, Design Thinking: The Ultimate Guide
