Hvordan kan du vite om det du lager har verdi?

Digitale tjenester i form av apper, websider og dingser med IOT utvikles og lanseres. Koden er optimalisert, integrasjonene er verifisert og grensesnittet (UX) er brukertestet og er iht designmanualen. La brukerne komme!

Tjenesten er kanskje tatt frem basert på en forretningsanalyse og har definerte mål. Jeg er heller ikke i tvil om at utviklingen, designet og UX’en er levert med god kvalitet og basert på innsikt som er tilgjengelig. Men hvordan vet du som kunde om tjenesten du har lansert lar deg nå målene og at resultatet gir den størst mulige verdien?

Vi ser i større og større grad at UX (User Experience) blir førende i digitale prosjekter hvor ide, konsept og gjennomføring ofte ledes av UX designere. Med ønske om å være brukersentrisk og hele tiden tenke hva brukeren har behov for så er nok dette et godt valg. De forvalter sin rolle godt og har metoder, kunnskap og skaffer innsikt som understøtter de valg som tas når en tjeneste utvikles. Men, og det finnes et definitivt men her…

A/B test som metode i datadrevet design (CRO)

Jeg leste med interesse en artikkel fra Marianne Person, UX Manager i Sopra Steria, om hvordan UX design konvergerer med CRO (konverterings optimalisering) og smelter sammen i datadrevet design! https://www.soprasteria.no/vi-mener/details/datadrevet-design-konverteringsoptimalisering-hva-er-det-og-hvorfor-er-det-nyttig. 

Eksemplet til Marianne tar utgangspunkt i nettbutikk som selger godteri. Kunden har et ønske om å øke konverteringsraten fra 10% til 15%. Det er sett på flere potensielle løsninger for å øke konverteringen og den hypotesen som velges ut for testing er "Knappen for å legge til i handlekurv ligger utenfor det naturlige synsfeltet til brukerne og ved å flytte knappen vil vi påvirke dem til å gjennomføre et kjøp". Som metode kjøres det en klassisk A/B test.

Som illustrasjon på hva datadrevet design kan være fungerer eksemplet fint. Men det feier elegant unna en del kompleksitet hvor godteributikken faktisk taper penger til tross for at målet om 15% konvertering inntreffer!

Vi i Optimizely mener at virkelig datadrevet design både starter mye tidligere i livssyklusen til en tjeneste (mer om det litt lengre ned i artikkelen) samt at den må ta inn over seg en annen grad av kompleksitet. 

Et liknende eksempel finner vi fra Barack Obama sin kampanje i 2008 (det var på grunnlag av arbeidet som ble gjort i denne kampanjen at selskapet Optimizely ble startet). Følgende oversikt beskriver kompleksiteten på noe så enkelt som en knapp.

Hadde Obama kun testet knappen mot uregistrerte brukere hadde hans kampanje gått glipp av enorme summer fra de som allerede var registrert og returnerende donorer! 

Testen som eksemplifiseres i artikkelen til Marianne vil potensielt løse målet om 15% konverteringsrate. Men om de besøkende som handler stort og mye blir borte vil den totale omsetningen gå ned, selv om konverteringsraten går opp! Dette er bare ett lite eksempel på at noe så enkelt som en A/B test av en knapp skjuler en kompleksitet som må håndteres. 

Datadrevet design (eller CRO) kan ikke starte med flikking

Eksemplet med å flytte en knapp for å se om det kan påvirke resultatet er effektivt for å fortelle hva datadrevet design kan handle om. Men om du tenker at datadrevet design er noe som du begynner med etter at tjenesten er levert har du misset. Det finnes enormt mange muligheter tidligere i utviklingssyklusen som potensielt hadde gitt større verd enn det som tas frem som endelig løsning! 

En digital tjeneste er summen av alle funksjonene (og innholdet) den består av og disse har jo i seg selv blitt til basert på “noe”. Alle valg, alle interasjoner og alle sprinter som ledet opp til selve leveransen ble utført basert på “noe” som fortalte hvorfor utførelsen ble akkurat som den ble. Jeg har mine tvil om at dette “noe” var at målbar verdi var større enn alternativene som ble vurdert.

I Optimizely tror vi på at datadrevet design starter når prosjektet starter. Allerede ved første ide til hva tjenesten skal være, fungere og se ut vil det være veldig mange alternativer som også kan utgjøre tjenesten. 

Det er essensielt at man har verktøy og prosesser som kobler designere og utviklere og gjør det mulig å teste kontinuerlig og gjennom hele utviklingsløpet. Ikke bare for å finne ut hva som fungerer, men kanskje like viktig, hva som IKKE fungerer! Det siste poenget er ekstremt viktig fordi det sier noe om hva du ikke trenger å bruke tid på. I tillegg skaper det innsikt og forståelse som videre arbeid med tjenesten drar nytte av.

Om vi igjen bruker eksemplet fra godtebutikken kunne utformingen, funksjonene og innholdet på en produktsiden vært gjort på uendelig mange måter. Et gyldig spørsmål man kunne stilt leverandøren som har laget siden er hva som lå til grunn for akkurat de valgene som er gjort ? Hvorfor var knappen plassert der den gav 10% konvertering og ikke der den beviselig gir 15%?

Svaret er at det ikke er testet med vitenskapelig metode! Brukertesting, spørreundersøkelser, testing av trådskisser (wireframes), og andre metoder kan være indikatorer som forteller noe om retning, men det kan ikke være det du baserer valgene dine på. Skal du være datadrevet i din tilnærming må du basere det på faktisk innsikt fra faktiske brukere som faktisk bruker tjenesten. 

Alternativet er at du havner der en stor produsent av radioer, i følge mytene, havnet etter en fokusgruppe; Fokusgruppen ble brukt til å hjelpe til med å designe en radio. Spesielt hvilken farge radioen skulle ha. Alle var enige om at gul var den beste fargen. Det viste at merkevaren var «ung», «levende» og «spennende». Alle var enige om at gult var veien videre. På vei ut av gruppen ble hver deltaker tilbudt å ta med seg en radio hjem - flertallet tok den svarte radioen. 

Å stille noen et spørsmål om hva de tror, hjelper deg nødvendigvis ikke med å forstå hva de kommer til å gjøre.

Datadrevet design gir ingen mening om det drives i liten skala

En annen viktig grunn til at datadrevet design må starte tidlig er synliggjøringen av effekt og organisasjonens forståelse av hvorfor det er viktig (og riktig) å drive med testing og eksperimentering. Om det var like enkelt som i A/B test eksemplet over - en test, ett positivt resultat, så ville jo alle gjort dette.

Men realiteten er at du på 10 tester kun vil oppnå 2 positive resultater! Da sitter du altså igjen med 8 tester som gir ingen eller negativ målt verdi. Vil kunden betale 1350 kr i timen, eller leverandøren investere den samme summen, for at en designer skal teste 8 ting som ikke skaper verdi for oppdragsgiver? Legger du til at en test, som i Marianne sitt eksemplet med godtebutikken tar 2-4 uker så har du en kostnad som mest sannsynlig ikke veier opp for verdien av de 2 testene som faktisk gir verdi.

Har du derimot startet datadrevet design tidlig i prosjektet så vil både du og kunden ha sett at verdien av eksperimentering viser seg hele tiden. Fortsatt bare 2 av 10 positive, men verdien av de negative (eller de som ikke gir noe tellende resultat) har bidratt til at man IKKE å gå videre med noe som senere ville vist seg å ikke gi verdi. Tiden, pengene og prioriteringene har altså blitt brukt på riktige ting!

Faktisk er datadrevet design et spørsmål om hastighet og antall. 

Om vi kun regner på de testene som gir en positiv målt verdi gir en økning i antall tester en eksponentiell vekst.

Gjennom å ha startet tidlig har organisasjonen modnet, tankesettet blitt utvidet og verdiene av eksperimentering (datadrevet design) synliggjort. Basert på vår erfaring, som markedsledende innen verktøy for testing og eksperimentering, er det slike organisasjoner som lykkes og som bruker data fra vitenskapelig metode som grunnlag for beslutninger.

Verdsett og lær av feil, finn riktig vei raskere

Marianne understreker noe ekstremt viktig i sin artikkel, nemlig at om konverteringen ikke øker som følge av versjon B så er det også læring og må ikke sees på som et tap eller noe som er mislykket. Det er innsikt som skal brukes videre. Her er det utrolig mye å hente for datadrevet design fordi det som før var antagelser nå har blitt reell innsikt! Professor Stefan Thomke ved Harvard Business School, prisbelønnet forfatter av boken "Experimentation Works" snakker mer om dette her https://www.optimizely.com/no/insights/blog/verdsett-og-lar-av-feil-finn-riktig-vei-raskere/.

Oppsummering

Vi i Optimizely og Marianne er enig i veldig mye og spesielt det punktet om at datadrevet design er en kontinuerlig prosess. En kobling mellom det som skjer på design/UX og utviklingssiden, hvor man sammen jobber med hypoteser og kontinuerlig kan teste og eksperimentere, mener vi fundamentalt for å skape tjenester som gir størst mulig verdi for oppdragsgiver og bruker.

Et verktøy som Optimizely Full Stack står sentralt i dette fordi det blir en del av utviklingsmetodikken og kobler utvikler og designer. Optimizely Full Stack gjør det mulig å gradvis rulle ut nye funksjoner samtidig som man kan eksperimentere gjennom bla tradisjonelle A/B tester. Dette gjør at testing og eksperimentering blir en naturlig del av prosjektet og at beslutninger kan baseres på det som gir målbar verdi.

PS. Du kan starte med gradvis utrulling og eksperimentering gjennom vår tjeneste Free Rollouts. Les mer og opprett konto på https://www.optimizely.com/no/free-feature-flagging/.

PS2. Det er på sin plass å nevne at testing og eksperimentering ikke er begrenset til web. Verktøyene fra Optimizely kan teste alt som har en digital komponent (apper, skjermer, skjema mm).