Hur vet du om det du skapar har värde?

Digitala tjänster i form av appar, webbsidor och prylar med IOT utvecklas och lanseras. Koden har optimerats, integrationerna har verifierats och gränssnittet (UX) har testats av användare och uppfyller designmanualen. Låt användarna komma!

Tjänsten kan ha tagits fram baserat på en affärsanalys och ha definierade mål. Jag tvivlar inte heller på att utvecklingen, designen och UX:en har levererats med bra kvalitet och baserat på de insikter som finns tillgängliga. Men hur vet du som kund om tjänsten du har lanserat låter dig nå målen och att resultatet ger största möjliga värde?

Vi ser i allt större utsträckning att UX (User Experience) blir ledande i digitala projekt där idé, koncept och genomförande ofta leds av UX-designer. Med önskan om att vara användarcentrerad och hela tiden ta hänsyn till användarens behov så är detta nog ett bra val. De förvaltar sin roll väl och har metoder, kunskap och insikter som stödjer de val som görs när en tjänst utvecklas. Men, och det finns ett definitivt men här …

A/B-test som metod i datadriven design (CRO)

Jag läste med intresse en artikel från Marianne Person, UX Manager på Sopra Steria, om hur UX-design konvergerar med CRO (konverteringsoptimering) och smälter samman i datadriven design! https://www.soprasteria.no/vi-mener/details/datadriven-design-konverteringsoptimering-vad-er-det-og-hvorfor-er-det-nyttig. 

Mariannes exempel utgår från en nätbutik som säljer godis. Kunden vill öka konverteringsgraden från 10 procent till 15 procent. Man har sett på flera potentiella lösningar för att öka konverteringen, och den hypotes som har valts ut för testning är ”Knappen för att lägga till i varukorgen ligger utanför användarnas naturliga synfält och genom att flytta knappen påverkar vi hen att genomföra ett köp”. Som metod körs ett klassiskt A/B-test.

Exemplet fungerar bra som illustration på vad datadriven design kan vara. Men det sopar elegant en del komplexitet under mattan och godisaffären förlorar faktiskt pengar, trots att målet om 15 procents konvertering uppnås!

På Optimizely anser vi att verkligt datadriven design börjar mycket tidigare i en tjänsts livscykel (mer om detta lite längre ner i artikeln) och att den måste ta till sig en annan grad av komplexitet. 

Ett liknande exempel är Barack Obamas kampanj 2008 (det var på underlag av arbetet som utfördes i denna kampanj som företaget Optimizely startades). Följande översikt beskriver komplexiteten på något så enkelt som en knapp.

Hade Obama bara testat knappen mot oregistrerade användare hade hans kampanj missat enorma summor från de som redan var registrerade och regelbundna donatorer! 

Testet som exemplifieras i Mariannes artikel kan potentiellt bidra till att målet om 15 procents konverteringsgrad uppnås. Men om besökarna som handlar stort och mycket försvinner så kommer den totala omsättningen att minska, även om konverteringsgraden går upp! Detta är bara ett litet exempel på att något så enkelt som ett A/B-test av en knapp döljer en komplexitet som måste hanteras. 

Datadriven design (eller CRO) kan inte börja med taggning

Exemplet med att flytta en knapp för att se om det kan påverka resultatet är effektivt för att berätta vad datadriven design kan handla om. Men om du tänker att datadriven design är något som du börjar med efter att tjänsten har levererats har du fel. Det finns enormt många möjligheter tidigare i utvecklingscykeln som potentiellt hade gett större värde än det som tas fram som slutlig lösning! 

En digital tjänst är summan av alla funktioner (och innehållet) som den består av och dessa baseras ju i sig själva på ”något”. Alla val, alla interaktioner och alla sprinter som ledde upp till själva leveransen gjordes baserat på ”något” som berättade varför utförandet blev precis som det blev. Jag tvivlar på att detta ”något” var att mätbart värde var större än de alternativ som bedömdes.

På Optimizely tror vi på att datadriven design startar när projektet startar. Redan vid första idén till vad tjänsten ska vara, hur den ska fungera och se ut kommer det att finnas väldigt många alternativ som också kan utgöra tjänsten. 

Det är viktigt att ha verktyg och processer som kopplar samman designer och utvecklare och gör det möjligt att testa regelbundet och under hela utvecklingsprocessen. Inte bara för att ta reda på vad som fungerar, utan kanske – och minst lika viktigt – vad som INTE fungerar! Den sista poängen är extremt viktig eftersom den säger något om vad man inte behöver lägga tid på. Dessutom skapar det insikt och förståelse som man kan dra nytta av i det framtida arbetet med tjänsten.

Om vi återigen använder exemplet från godisbutiken så kunde utformningen, funktionerna och innehållet på en produktsida ha gjorts på oändligt många sätt. En relevant fråga man skulle kunna ställa till leverantören som har skapat sidan är vad som låg till grund för just de val som har gjorts. Varför var knappen placerad där den gav 10 procent konvertering och inte där den bevisligen ger 15 procent?

Svaret är att det inte har testats med vetenskaplig metod! Användartester, enkäter, tester av trådskisser (wireframes) och andra metoder kan vara indikatorer som berättar något om riktning, men ska inte vara det du baserar dina val på. Om du vill vara datadriven i ditt tillvägagångssätt måste du utgå från faktiska insikter från faktiska användare som faktiskt använder tjänsten. 

Alternativet är att du hamnar i samma situation som en stor producent av radioapparater, enligt myten, hamnade i efter att ha använt sig av en fokusgrupp. Denna fokusgrupp användes för att hjälpa till att designa en radio. Framför allt vilken färg radion skulle ha. Alla var överens om att gult var den bästa färgen. Det visade att varumärket var ”ungt”, ”levande” och ”spännande”. Alla var överens om att gult var vägen framåt. Efteråt blev varje deltagare erbjuden att ta med sig en radio hem – majoriteten tog den svarta radion. 

Att ställa en fråga om vad de tror, hjälper dig nödvändigtvis inte att förstå vad de kommer att göra.

Datadriven design är inte meningsfull om den används i liten skala

En annan viktig anledning till att datordriven design måste börja tidigt är att synliggöra effekten av och organisationens förståelse för varför det är viktigt (och rätt) att göra tester och experimentera. Om det var lika enkelt som i A/B-testexemplet ovan – ett test, ett positivt resultat – så skulle ju alla göra det.

Men sanningen är att du på 10 tester bara kommer att uppnå 2 positiva resultat! Då återstår alltså 8 tester som ger inget eller negativt uppmätt värde. Vill kunden betala 1 350 kr i timmen, eller leverantören investera samma summa, för att en designer ska testa 8 saker som inte skapar värde för uppdragsgivaren? Lägger du till att ett test, som i Mariannes exempel med godisbutiken, tar 2–4 veckor så har du en kostnad som mest sannolikt inte väger upp värdet av de 2 testen som faktiskt ger värde.

Har du däremot startat datadriven design tidigt i projektet så kommer både du och kunden ha sett att värdet av experimentering visar sig hela tiden. Fortfarande bara 2 av 10 positiva, men värdet av de negativa (eller de som inte ger något avgörande resultat) har bidragit till att man INTE går vidare med något som senare skulle visa sig inte ge värde. Tid, pengar och prioriteringar har alltså lagts på rätt saker!

Faktum är att datadriven design är en fråga om hastighet och antal. 

Om vi endast räknar på de tester som ger ett positivt uppmätt värde så ger en ökning av antalet tester en exponentiell tillväxt.

Genom att ha startat tidigt har organisationen mognat, tankesättet utökats och värdena av experimentering (datadriven design) synliggjorts. Baserat på vår erfarenhet, som marknadsledande inom verktyg för testning och experimentering, är det dessa organisationer som lyckas och som använder data från vetenskaplig metod som underlag för beslutsfattande.

Uppskatta och lär av misstag, hitta rätt väg snabbare

Marianne understryker något extremt viktigt i sin artikel, nämligen att om konverteringen inte ökar till följd av version B så är det också lärande och får inte ses som en förlust eller ett misslyckande. Det är insikter som ska användas vidare. Här finns otroligt mycket att hämta för datadriven design eftersom det som förut ansågs som antaganden nu har blivit verklig insikt! Professor Stefan Thomke på Harvard Business School, prisbelönt författare till boken ”Experimentation Works”, berättar mer här https://www.optimizely.com/no/insights/blog/verdsett-og-lar-av-feil-finn-riktig-vei-raskere/.

Sammanfattning

Vi på Optimizely och Marianne är eniga i väldigt mycket och i synnerhet om att datadriven design är en kontinuerlig process. En koppling mellan det som sker inom design/UX och på utvecklingssidan, där man tillsammans jobbar med hypoteser och kontinuerligt kan testa och experimentera, menar vi är avgörande för att skapa tjänster som ger största möjliga värde för uppdragsgivaren och användaren.

Ett verktyg som Optimizely Full Stack står i centrum eftersom det blir en del av utvecklingsmetoden och kopplar samman utvecklare och designer. Optimizely Full Stack gör det möjligt att successivt rulla ut nya funktioner samtidigt som man kan experimentera med bland annat traditionella A/B-tester. Detta gör att testning och experimentering blir en naturlig del av projektet och att beslut kan baseras på det som ger mätbart värde.

PS. Du kan börja med gradvis utrullning och experimentering genom vår tjänst Free Rollouts. Läs mer och skapa ditt konto på https://www.optimizely.com/se/free-feature-flagging/.

PS2. Det är på sin plats att nämna att testning och experiment inte är begränsade till webben. Verktygen från Optimizely kan testa allt som har en digital komponent (appar, skärmar, scheman m.m).