Hopp til hovedinnhold

Design og UX / 5 minutter /

Snakk med de det gjelder!

I Kantega er vi opptatt av å skape verdi for kundene våre og da må vi måle ofte og korrigere underveis. Brukerne er våre viktigste kilder; hva trenger de, hva gjør de og hvorfor? Her er noen eksempler på hvordan vi får de svarene vi trenger for å lykkes med et prosjekt.

I Kantega er vi opptatt av å skape verdi for kundene våre og da må vi måle ofte og korrigere underveis. Brukerne er våre viktigste kilder; hva trenger de, hva gjør de og hvorfor? Her er noen eksempler på hvordan vi får de svarene vi trenger for å lykkes med et prosjekt.

Men først: hvorfor skal vi måle? Kontinuerlig måling av effekt underveis i prosjektet reduserer usikkerhet og øker sannsynligheten for at vi lykkes ved at vi investerer i de riktige tingene. Vi reduserer kostnader ved at vi fanger opp dårlige løsninger tidligere og kan introdusere gode løsninger raskere. Ved å fokusere på å lage de riktige tingene tidlig reduserer vi også unødvendig tidsbruk på produktdesign og utvikling. På toppen av det hele får vi et bedre produkt fordi vi jobber brukersentrert.

graf som viser at usikkerheten reduseres i tid med testing og brukerinvolvering før vi investerer for mye
graf som viser at usikkerheten reduseres i tid med testing og brukerinvolvering før vi investerer for mye

Figur: Vi reduserer usikkerheten med testing og brukerinvolvering før vi investerer for mye

Figur: Vi reduserer usikkerheten med testing og brukerinvolvering før vi investerer for mye

Det er mange måter å skaffe innsikt og måle effekt på. Når vi involverer brukere er det viktig å tenke på at det ikke alltid er samsvar med hva de sier (holdninger) og hva de faktisk gjør (adferd). Vi kan samle mye data (kvantitativt) eller vi kan klare oss med litt mindre (kvalitativt) for å få en ide om vi er på rett vei. Metodene supplerer hverandre. Vi bruker de kvalitative metodene for å få svar på hvorfor folk gjør som de gjør slik at vi forstår de kvantitative dataene bedre.

Ulike kvantitative og kvalitative verktøy vist i forhold til hva brukeren sier at de gjør og faktisk gjør
Ulike kvantitative og kvalitative verktøy vist i forhold til hva brukeren sier at de gjør og faktisk gjør

Her er noen eksempler på hvordan vi har fått innsikt og målt effekt i prosjekter Kantega har gjennomført.

Statistikk

Bruksstatistikk er en kvantitativ metode som forteller oss noe om hva mange brukere gjør. Vi samler informasjon om reell adferd og gjør endringer basert på det. Hva klikker de på, hva blir brukt, kjøpt, churn og hva gjør konkurrentene? Mange bruker Google Analytics som webanalyseverktøy, men vi bruker også mange andre verktøy for å spore hva som skjer i en løsning.

A/B-testing er en effektiv måte å benytte statistikk på som kan stoppe diskusjoner og synsing om hva som er best. Vi lanserer to varianter av samme funksjonalitet samtidig og hvis den ene varianten fører til økt konvertering er valget ofte veldig enkelt. Dette er data som ledelsen forstår.

Undersøkelser

Mange forbinder brukerundersøkelser med skjema, mange spørsmål og at man må invitere minst 1000 respondenter. Det kan gjøres enklere. Smilefjes eller likes på en nettside kombinert med ett kommentarfelt kan raskt gir oss svar på ting vi lurer på. Opplevde brukeren funksjonaliteten som nyttig, er det noe man savner etc.?

Vi har også benyttet kommentarfelt fra sosiale medier eller fra app-butikkene for å få vite hva brukerne synes om produkt vi har laget. Ved å integrere slike kommentarer inn i prosjektgruppens Slack-kanal eller lignende får vi raskt tilbakemeldinger som vi kan diskutere og eventuelt agere på.

Dette er holdningsbaserte data så man skal være forsiktig med å trekke for sterke konkusjoner, men det gir ofte innsikt som vi kan bygge videre på med kvalitative intervjuer eller tester.

Intervjuer

Brukerintervjuer er nyttig for å bedre forstå hvilke problemer man skal løse, for å teste ut hypoteser tidlig i prosjektet eller rett å slett for å finne ut hva vi skal lage. Vi spør om hva de gjør i dag, hva som motiverer dem og hvilke utfordringer de har. Her må vi huske å ikke stille ledende spørsmål slik at vi faktisk får en realistisk tilbakemelding som gir verdi og læring til prosjektet. Ved å stille åpne spørsmål får vi ofte vite mye mer enn vi hadde håpet på!

Brukertest

Brukertest er ofte det først man tenker på når det gjelder måling og involvering av brukere. Problemet er at mange forbinder det med testing av løsningen før lansering, men da er det ofte for sent. Man kan brukerteste prototyper før kodingen begynner. Jo tidligere vi brukertester jo raskere får vi eventuelt korrigert produktet basert på innsikt fra brukeren.

Når vi brukertester benytter vi ofte kombinasjon av intervju og observasjon. Vi gir brukeren oppgaver, observerer hva de gjør og ber dem fortelle hva de tenker når oppgavene løses. Vi passer på å spørre hvorfor de gjør som de gjør, hvor viktig er det for dem og om de har andre behov. Kanskje vi har fokusert på feil ting?

Vi har også benyttet digitale løsninger hvor vi kan laste opp løsningen eller prototypen vi vil teste. Vi lager ett sett med oppgaver og velger hva slags brukere vi vil teste på. Allerede registrerte brukere kan gjennomføre testen og hele testen dokumenteres med film av skjermbilder, brukerens ansikt og hva de sier underveis. Testen kan være gjennomført og dokumentert før vi kommer på jobb neste dag!

Gueriljatest

Mange tror at gjennomføring av en brukertest er veldig omfattende; man må skaffe brukere, avtale tid, sted etc. Det trenger ikke være det. Vi har gueriljatestet funksjonalitet ved at vi tar med oss en enkel prototype og går ut på gaten eller i kantina for å spørre tilfeldige folk om de kan teste den. Det gir oss en rask tilbakemelding på om vi er på rett vei og man får testet funksjonalitet raskt.

Kontekst er viktig

En annen viktig ting vi har erfart rundt brukertesting er fordelen med å gjennomføre testen i riktig kontekst. Ikke invitere brukere inn til en testlab, men å teste den der de skal bruke den. Da får vi mer reelle reaksjoner og det er enklere for brukeren å relatere oppgaven til sin egen situasjon. Vi har eksempler på funksjonalitet som har «bestått» brukertest av både prototype og produsert løsning i lab, men da den ble testet der den faktisk skulle brukes ble den oversett i ett tilfelle, eller det viste seg at funksjonalitet var overflødig i ett annet tilfelle. Da hjelper det ikke hvor brukervennlig den er.

En fra Kantega som utfører brukertest på to menn fra statens vegvesen.
En fra Kantega som utfører brukertest på to menn fra statens vegvesen.

Brukertest i felt av mobilløsningen til Statens vegvesens Vegkart ga oss viktige tilbakemeldinger om bruk som vi ikke hadde avdekket om vi satt inne på et kontor.

Brukertest i felt av mobilløsningen til Statens vegvesens Vegkart ga oss viktige tilbakemeldinger om bruk som vi ikke hadde avdekket om vi satt inne på et kontor.

Kundesupport

Observasjon av en kundegruppe på kundesupport kan være en gullgruve for å finne ut hvor bra – eller dårlig løsningen fungerer. Ta en dag på kundesenteret på medlytt for å høre hva folk ringer om når de synes noe er vanskelig eller de ikke forstår. Eller følg med på kundechatten. Det kan være mange grunner til at det er vanskelig og vi sjekker alltid ut hvorfor brukerne gjør som de gjør. Det er ikke alltid en quickfix er den rette løsningen på lang sikt og det kan hende at problemet ligger et annet sted enn først antatt.

Gå i brukerens sko

Vi synes også at det er lurt å bruke produktet selv, enten det produktet man jobber med eller konkurrentenes. Det er mye læring i å kjenne litt på frustrasjonen av det som ikke fungerer og gleden over noe som er bra.

Hvem skal teste

I Kantega er det ikke bare UX-avdelingen som er opptatt av måling. Vi tar ofte med noen fra teamet som observatører når vi tester, eller hele teamet observerer testen over video. Da øker forståelsen for hvorfor noe eventuelt må endres og utviklere har ofte minst like gode forslag til hvordan problemet kan løses for brukerne når de selv ser hva problemet er, både backend og frontend.

Mange av våre utviklere er engasjert i måling og blir motivert av å se at det de lager fungerer. Deres råd er:

  • Måle først, spørre etterpå
  • Finn ut hvor lite det er mulig å måle
  • Visualiser effekten, gjør det enkelt for beslutningstakere å ta gode valg
  • Ta oss med når dere tester, da tar vi mer eierskap til problemene som eventuelt skal løses

Og husk at alle løsninger har brukere, ikke bare de med et publikumsgrensesnitt. Saksbehandlere er brukere av fagsystemer. Andre utviklere er brukere av for eksempel en plattform eller et API. De skal også ha en god brukeropplevelse når de skal ta det i bruk.


Snakk med de det gjelder!