Brukertest eller A/B-test?
En brukertest forklarer hvorfor noe ikke fungerer: Du observerer noen få personer som bruker tjenesten, og ser hvor de står fast. En A/B-test måler hva som fungerer bedre: To varianter vises for mange besøkende, og utfallet telles opp. Brukertester passer før noe er bygget og krever få deltakere; A/B-tester krever mye trafikk og passer etter lansering.
Brukertesting og A/B-testing høres ut som to måter å gjøre det samme på, nemlig å teste en digital tjeneste. I virkeligheten svarer de på ulike spørsmål, krever ulike forutsetninger og hører hjemme i ulike faser. Velger du feil metode for situasjonen, risikerer du enten et svar du ikke kan stole på, eller en dyr test som ikke lot seg gjennomføre.
Grunnforskjellen: hvorfor mot hva
Den avgjørende forskjellen er hvilket spørsmål metoden besvarer.
En brukertest er kvalitativ. Du lar noen personer bruke tjenesten mens du observerer, og du ser hvor de nøler, misforstår eller gir opp. Fremfor alt får du høre hvorfor: De tenker ofte høyt, og du forstår logikken bak feiltrinnene. Metoden svarer på spørsmålet: Hvorfor fungerer ikke dette?
En A/B-test er kvantitativ. Du viser besøkende to varianter av samme side, deler trafikken mellom dem og måler hvilken som presterer best: flere kjøp, flere registreringer, mindre frafall. Du får ikke vite hvorfor, men du får statistisk belegg for hva som fungerer bedre. Metoden svarer på spørsmålet: Hvilken variant vinner?
Kort sagt: Brukertesten forklarer årsaken, A/B-testen beviser utfallet. Den ene gir deg forståelse, den andre gir deg tall.
Skala, trafikk, kostnad og tid
Metodene skiller seg like mye i hva de krever som i hva de gir.
| Metode | Krever og koster |
|---|---|
| Brukertest | En håndfull deltakere, ingen trafikk: raskt i gang, lav terskel |
| A/B-test | Mye trafikk og en tjeneste i drift: lengre løpetid, teknisk oppsett |
En brukertest trenger ikke mer enn fem eller seks deltakere for å avdekke de fleste alvorlige problemene. De samme hindringene rammer nemlig gjerne flere. Testen kan gjennomføres på en prototyp før noe er bygget, og du kan være i gang i løpet av noen dager. Kostnaden ligger i tiden det tar å rekruttere, observere og sammenstille.
En A/B-test forutsetter en fungerende tjeneste med reell trafikk. For å skille en faktisk forbedring fra tilfeldigheter kreves nok besøkende i hver variant, ofte tusenvis per uke. Har siden lite trafikk, tar testen urimelig lang tid eller gir ikke noe sikkert svar. Kostnaden ligger i det tekniske oppsettet og i ventetiden før resultatet er statistisk sikkert.
Beslutningsmatrise: fase og trafikkvolum
Hvilken metode som er riktig, avgjøres fremfor alt av hvor i livssyklusen du er, og hvor mye trafikk du har.
- Før utvikling eller lansering: brukertest, alltid. Det finnes ingen trafikk å måle på, og det er nå det er billigst å oppdage at brukerflyten er tenkt feil. En test på en prototyp kan spare uker med arbeid på funksjonalitet som blir ferdig bygget, men ubrukelig.
- Etter lansering, lite trafikk: fortsatt brukertest. Uten tilstrekkelig volum er det ikke mulig å kjøre en pålitelig A/B-test, og det kvalitative svaret er mer verdt enn et usikkert tall.
- Etter lansering, mye trafikk: A/B-test for å finpusse. Når du har volum, kan du bevise hvilken overskrift, knapp eller layout som faktisk konverterer best, i stedet for å gjette.
Et konkret eksempel: En bedrift skal lansere en ny kasse i nettbutikken sin. Først testes den på fem brukere som får handle i en prototyp. Det avslører at et obligatorisk felt forvirrer, og feltet fjernes før lansering. Et halvår senere, når trafikken har vokst, kjøres en A/B-test på to varianter av knappeteksten for å hente ut de siste prosentene i konvertering. Riktig metode i riktig fase, ikke det ene i stedet for det andre.
Den vanligste feilen: feil metode for trafikken
Den dyreste feilen er å kjøre en A/B-test på en tjeneste som ikke har trafikken til det. To varianter settes opp, ukene går, og tallene peker hit og dit uten noen gang å bli sikre. Grunnlaget er rett og slett for lite. Man trekker likevel en konklusjon, ofte feil, og bygger videre på den. En kvalitativ brukertest ville ha gitt et tydelig svar på en brøkdel av tiden.
Den motsatte feilen finnes også: å stole utelukkende på brukertester lenge etter lansering, når det finnes mye trafikk og en A/B-test kunne ha avgjort en uenighet objektivt. Hva fem personer mener, er utmerket for å finne problemer, men svakt som bevis for hvilken av to fungerende varianter som selger best. Riktig metode følger av hvor du er og hvor mye trafikk du har, ikke av vane eller av hvilken metode som føles finest.
Vil du finne ut hvilken metode som passer for akkurat din situasjon? Både brukertester og konverteringsarbeid inngår i tjenestene våre. Ta kontakt, så ser vi på hvor du står.
Ofte stilte spørsmål
Hva er forskjellen på brukertest og A/B-test?
En brukertest er kvalitativ: Du lar noen få personer bruke tjenesten og observerer hvor de nøler og hvorfor. En A/B-test er kvantitativ: Du viser to varianter for et stort antall besøkende og måler hvilken som gir best utfall. Brukertesten forklarer hvorfor noe skjer, A/B-testen beviser med tall hva som skjer. De svarer på ulike typer spørsmål.
Når bør jeg bruke en brukertest i stedet for en A/B-test?
Bruk brukertest når du vil forstå hvorfor noe ikke fungerer, og særlig før tjenesten er bygget eller lansert. Den krever bare en håndfull deltakere og avdekker problemer som tall ikke kan forklare. En A/B-test forutsetter at det allerede finnes en fungerende tjeneste og mye trafikk å måle på, så den passer senere i livssyklusen.
Hvor mye trafikk krever en A/B-test?
Mer enn mange tror. For å skille en reell forbedring fra tilfeldigheter trengs nok besøkende og konverteringer i hver variant, ofte tusenvis per uke for et pålitelig resultat. Har siden lite trafikk, tar testen urimelig lang tid eller gir ikke noe sikkert svar i det hele tatt. Da er en kvalitativ brukertest nesten alltid en bedre investering.
Hvor mange deltakere trengs i en brukertest?
Færre enn man tror. Med bare fem deltakere avdekker du som regel de fleste av de alvorligste problemene i en brukerflyt fordi de samme hindringene gjerne rammer flere. Poenget er ikke statistisk sikkerhet, men å se mønstre i atferden. Flere deltakere gir marginalt mer, men gevinsten avtar raskt etter den første håndfullen.
Kan man bruke begge metodene i samme prosjekt?
Ja, og de utfyller hverandre godt. Et vanlig opplegg er å bruke brukertester før og like etter lansering for å finne og forstå problemer, og deretter A/B-tester for å finpusse detaljer når trafikken har vokst. Kvalitativt for å vite hva som bør endres, kvantitativt for å bevise at endringen faktisk hjalp.