Målinger i praksis: Sånn fant jeg gode produktmålinger

I denne artikkelen går jeg gjennom tankeprosessen jeg hadde da jeg valgte hvilke målinger jeg skulle sette opp. Det starter med en liten produktanalyse. Deretter definerer jeg KPI-ene jeg ville ha, og diskuterer hvordan jeg kan måle disse i praksis. Til slutt oppsummerer jeg prosessen og læringspunktene. Oppsummeringen kan leses uten mer kontekst, så hvis du har dårlig tid anbefaler jeg å scrolle til bunnen av artikkelen!

Produktanalyse

For å finne gode målinger gjorde jeg først en enkel analyse av produktet i tre deler:

1. Hva er produktet?
2. Hvilke problemer løser produktet for bruker?
3. Hva er verdien for “organisasjonen” (meg)?

Produktanalyse del 1: Hva er produktet?

Når man strikker, står det ofte i strikkeoppskriften at man skal “felle jevnt fordelt” eller “øke jevnt fordelt”, uten å beskrive i detalj hvordan det skal gjøres. Å øke med 10 masker jevnt fordelt når det er 100 masker på en pinne, er enkelt: Strikk 10 masker, øk med én, gjenta til runden er slutt. Men det er litt mer komplisert å øke 13 masker fra 71, for eksempel. Dette er problemet som strikkekalkulatoren løser. Bildene under viser et eksempel.

Disse skjermbildene viser hoveddelene av nettsiden, med unntak av noen ting. For å finne gode målinger burde jeg vite hva jeg måler, så jeg har laget en liste av alt produktet består av:

• En gratis nettside
• Regner ut hvordan man feller og øker jevnt fordelt
• Tellehjelp
• Reklame
• Tilbakemeldingsfunksjonalitet
• Språkstøtte for norsk, dansk og engelsk
• Forklaring av hvordan man regner det ut selv
• Knapper for å dele og/eller skrive ut oppskriften

Det er enklere å tenke på målinger i kontekst av en brukerreise. For strikkekalkulatoren vil en typisk brukerreise se slik ut:

Produktanalyse del 2: Hvilke problemer løser produktet?

I utgangspunktet løser strikkekalkulatoren et lite matteproblem som kan være tidkrevende å regne ut riktig selv. Men det finnes mange andre tjenester som gjør akkurat dette. Problemet er at disse andre tjenestene enten er en mobilapp man må laste ned, eller engelskspråkelige nettsider med dårlig brukeropplevelse. I tillegg nøyer de fleste kalkulatorene seg med en veldig overordnet oppskrift, mens min gir brukeren hva de skal gjøre steg for steg for å få det helt jevnt. Dette er hovedfunksjonaliteten, men jeg prøver å løse noen tilleggsproblemer også:

1. Steg-for-steg-oppskriften pares veldig godt med tellehjelpen, som gjør det enklere å holde styr på hvor lang man har kommet.
2. Knappen for å dele oppskriften er ment å svare på noe jeg har sett mye av i strikkegrupper på Facebook: Folk som spør “Hvordan feller jeg jevnt fra 87 til 66 masker?”. I trådene under kommer det side opp og side ned med bilder fra strikke-apper og nettsider. Derfor tenkte jeg det var lurt å gjøre det enkelt å dele oppskrifter.
3. “Skriv ut”-knappen kommer av en teori jeg har om at noen strikkere har samme plagg de strikker mange ganger, og heller vil printe ut oppskriften enn å gå inn på nettsiden hver gang.
4. Deler av produktet — reklame og tilbakemeldingene — har jeg ikke lagt til med hypotesen om at de dekker et brukerbehov.

Bildet under har en fullstendig liste av funksjonalitet, og visualiserer hvordan delene av produktet kobles opp mot problemene det løser. Merk at venstre side, “Hva er produktet?”, er harde, kalde fakta — mens koblingen til høyre side, og egentlig alle problemene jeg tror brukerne har, er hypoteser.

Produktanalyse del 3: Hva er målet?

Forrige seksjon handlet om hva produktet gir til brukerne. Men for å vite hva jeg skal måle, burde jeg også ha et reflektert forhold til hva produktet gir meg. Hvorfor lager jeg dette? Hva vil jeg oppnå? Det en god parallell til “ekte” produkter som eies av organisasjoner: Hva får organisasjonen ut av å lage produktet?

Den aller største grunnen til at jeg lager dette produktet, er at jeg synes det er gøy å lage noe som folk bruker, og som gir dem verdi. Det er spesielt morsomt å jobbe mot å lage den beste strikkekalkulatoren tilgjengelig. Ellers setter jeg pris på å kunne utfolde meg teknologisk uten begrensningene ute på oppdrag. Dette, koblet med å få drive produktutvikling på helt egen kappe, gir meg godt læringsutbytte. En annen ting jeg liker er algoritmer — motoren bak strikkeoppskriften er overraskende komplisert. Til sist synes jeg det er gøy å tjene noe via reklame på hobbyprosjektet mitt — det beviser liksom at det gir verdi, det tar hånd om alle kostnader knyttet til hosting, og gir meg muligheten til å utforske verktøy som koster penger uten å måtte investere “fra egen lomme”.

Da jeg konkretiserte disse målene for meg selv, var det veldig enkelt å drodle litt rundt potensielle målinger samtidig. Dette visualiserer jeg under. Merk at jeg ikke har følt behov for å koble alle verdipunktene opp mot en måling.

De viktigste målingene: KPI-er

I løpet av produktanalysen kom jeg på veldig mange potensielle målinger. Jeg kommer til å vise flere konkrete målinger i neste artikkel, men akkurat nå vil jeg trekke fram de viktigste. Når jeg ser gjennom hva produktet er, hypotesene om brukerverdi, og hvorfor jeg lager produktet, er det noen måltall som skiller seg ut:

1. Antall brukere
2. Andelen brukere som faktisk bruker strikkekalkulatoren
3. Andelen tilbakemeldinger som er “Bra” eller “OK”

Hvis alle disse tallene går opp, så betyr det at mange får verdi ut av produktet mitt, og det er akkurat det jeg vil. Jeg velger å la disse tre metrikkene være produktets KPI-er, Key Performance Indicators.

Hvordan måle bruk av kalkulatoren?

KPI nummer 1 og 3 er ganske enkle å måle, men nummer 2 “Andelen brukere som faktisk bruker strikkekalkulatoren” krever litt mer tenking. Hvordan kan jeg måle om strikkekalkulatoren faktisk blir brukt?

Forslag 1: Klikk på “Regn ut”

Et mulig måltall er å se på antallet som fyller ut tall og klikker på “Regn ut”. Det er et OK mål, men brukerne kan i teorien fylle ut tallene, se på oppskriften, ikke like den, og forlate siden.

Forslag 2: Tidsbruk

En indikasjon på at oppskriften blir brukt, er at man blir en stund på siden. Det er sånn produktet er ment å bli brukt: At man ser på oppskriften mens man strikker selve runden. Hvor lenge skulle det vært, i så fall? La oss si at man har 50 masker på pinnen, et ganske beskjedent antall. Et raskt Google-søk tilsier at gjennomsnittlig strikkehastighet er 20–30 masker i minuttet, og verdensrekorden ligger på 118 masker i minuttet. Med disse tallene som bakgrunn, velger jeg å tenke at en rask strikker vil gjøre ferdig strikkeoppskriften fra kalkulatoren på cirka 1 minutt.

Neste iterasjon av KPI-en kunne dermed vært følgende: Antall brukere som klikker på “Regn ut” og som er på siden i, la oss si, 80 sekunder. Da har jeg lagt på 20 sekunder for å ta høyde for tiden det tar å forstå hvordan siden brukes, taste inn tallene, og scrolle ned til oppskriften. Dette er et bedre mål på bruk, men jeg er ennå ikke helt fornøyd.

Forslag 3: Tidsbruk etter klikk

Noen brukere knoter nemlig en del med å legge inn de tallene — én grunn til dette kan være at strikkeoppskrifter ofte sier “fell 8 masker jevnt fordelt blant 79”, og i min strikkekalkulator skal man da skrive inn tallene 79 og 71, ikke 79 og 8. Det kan være at brukeren knoter såpass mye med tallene at de bruker opp alle de 80 sekundene på dette, uten at de faktisk har brukt oppskriften. Et enda bedre mål hadde vært om brukeren hadde siden oppe i f.eks. 70 sekunder etter klikket på “Regn ut”. Men jeg har valgt å gå enda et steg videre.

Forslag 4: Oppskrift i viewport

Jeg velger å sette KPI ut i fra følgende mål: Brukeren har oppskriften i viewport i 60 sekunder. Det er det nærmeste jeg kommer å måle at brukeren faktisk ser på oppskriften. Det er fremdeles ikke perfekt, brukeren kan for eksempel gå til oppskriften og bare forlate laptopen. Men jeg synes denne målingen er mer enn god nok. Hvis strikkekalkulatoren var en bitteliten del av en stor applikasjonsportefølje, så hadde jeg nok ikke brukt såpass mye tid på å finne et godt mål på bruk — antall klikk på “Regn ut” og tid på siden hadde holdt i massevis.

Konklusjon

Her kommer en oppsummert beskrivelse av hvordan jeg kom fram til målingene jeg ville ha. Dette er ikke tatt fra et rammeverk eller noe — det er bare denne flyten jeg naturlig fulgte underveis i prosessen. Take it or leave it!

1. Jeg beskrev hva produktet er. Allerede her dukket det opp mange tanker om hva jeg burde måle.
2. Jeg definerte brukerreisen. Dette var nyttig innsikt da jeg skulle se på hvilke mål jeg ville brukeren skulle oppnå.
3. Jeg konkretiserte brukerproblemene jeg ville løse. Flesteparten av problemene hadde jeg allerede i hodet, men det satte meg i riktig modus å måtte skrive ned alle eksplisitt.
4. Jeg konkretiserte hva jeg selv fikk ut av å lage produktet. Det er alltid nyttig å ha et reflektert forhold til hvorfor man investerer tid i noe, og dette ga ekstra fart på tankene om hvilke målinger jeg ville ha.
5. Jeg skrev ned alle de aktuelle målingene som kom opp da jeg gikk gjennom punktene over.
6. Jeg definerte KPI-er ut i fra alt det tidligere arbeidet jeg hadde gjort. Mange målinger er interessante, men jeg identifiserte et fåtall målinger som jeg syntes ga god overordnet innsikt i verdien til produktet.
7. Jeg analyserte nøye hvordan jeg kunne måle den ene KPI-en. Det er verdt å bruke ekstra tid på de viktigste tallene.

Hvis jeg skulle gjort samme øvelse en gang til, ville jeg strukturert det litt mer og blant annet koblet målingene til brukerbehovene jeg skal løse. Jeg har oppsummert prosessen i bildet under.

Vil du se flere målinger, og vite hvordan jeg satte opp målingene med Posthog? Følg med i neste artikkel!