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 i henhold til 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.
