Eksperimenter og frustrationer

Hvis du arbejder på et digitalt produkt, så kender du måske følelsen af at sende en feature ud, du ikke helt ved om er helt optimal. Vi tror, det er det bedste design, men er det faktisk det? Får vi mest muligt ud af den her feature? For at løse den problemstilling benytter rigtigt mange virksomheder sig af værktøjer som A/B tests.

Det er en måde at eksperimentere med features på. Så i stedet for at sende en helt ny feature ud til alle brugere på én gang, så lancerer man typisk to forskellige udgaver af en feature til en lille gruppe brugere. Det lader man køre indtil man har data nok til at træffe en beslutning om hvilken udgave, der er bedst.

Det kan være et vildt godt værktøj, men det kan også være et frygteligt et. Og det har det med at opføre sig anerledes alt efter, hvilken type virksomhed du befinder dig i.

Startups

I startups opstår A/B tests ofte som et skridt på vejen mod en modning af virksomheden. Det er skridtet væk fra bare at sende hvadsomhelst ud til brugeren. Det er også et tegn på, at produktafdelingen er ved at blive stærkere og dygtigere. Nu vil de undersøge, hvad der virker, og hvad der ikke gør. På dette stadie er det ofte med hypoteser som "hvis vi flytter denne knap, kan vi så øge conversion?"

Så er der ét team, der sender én A/B test ud og venter indtil den lille brugerbase har genereret nok data til at kunne forstå, hvad der sker. Altså hvis de er heldige. Ellers har de måske endnu ikke nogle dataeksperter, der kan hjælpe dem med at forstå at en uges test med en brugerbase på 1000 brugere ikke er nok til at få meningsfuldt data. Måske øges conversion endda men det er svært at sige, om det var knappens nye placering der egentlig var årsagen.

Når testen er færdig, så tager de en beslutning om det ene eller det andet og fortsætter til den næste feature. Hvis de er gode husker de at rydde op i den kode, der starter A/B testen. Men som regel har de for travlt med nye features.

Scale-ups

Nu er tilgangen lidt mere moden. De er hyret minimum én data scientist, der kan hjælpe med at definere gode metrics og sørge for, at de tests, der bliver lavet giver nogenlunde mening. Nu er der også flere teams, der laver eksperimenter på samme tid i forskellige områder af produktet. Hvis virksomheden er styret af en lidt træls produkttænkning, så bliver der måske lagt lidt for meget værdi i antallet af eksperimenter fremfor resultaterne af dem. Så teams der kan skyde mange eksperimenter ud bliver pludseligt set som de produktive. Jeg har endda arbejdet steder, hvor der blev sat målsætninger op for hvor mange eksperimenter, man mindst skulle ramme som team.

Det er en kæmpe fejl, for det er meget let at skyde mange meningsløse eksperimenter ud. At flytte en knap en pixel hver dag er ikke noget, der skaber værdi. I stedet skal man se på den værdi, de skaber og ikke antallet. Derfor bør fokus være på gode metrics og hypoteser, der bygger på brugerundersøgelse og data.

Store virksomheder

Pludseligt går det stærkt. Ikke bare arbejder mange teams på forskellige A/B tests på én gang, de tester også på det samme område på én gang. Da du som startup og scale-up måske havde én test kørende i checkout flowet, så har du nu 5 forskellige tests på checkout flowet på én gang. Og det kan skabe en række helt store problemer for jer og for jeres brugere.

Jeg oplevede ofte, at:

• Et team aldrig anede hvilke tests, der allerede kørte. Det kan nemt føre til, at man lancerer lignende eller ligefrem modstridende eksperimenter på samme tid.
• Brugerne får en forvirrende oplevelse på tværs af de aktive eksperimenter. Kombinationen af to eksperimenter kan medføre, at checkout flowet ikke længere er brugbart.
• Det er umuligt at teste. Når checkout flowet har 5 eksperimenter kørende, så er det stort set umuligt at teste brugeroplevelsen: For hvad er egentlig forventligt? Hvad sker der, hvis bruger 1 er i to eksperimentgrupper, men bruger 2 er i 4 eksperimentgrupper? Hvad forventer vi, der sker? Og hvordan tester vi det?

Som stor virksomhed er der modenhed omkring data og værktøjer til at teste med, men der mangler ofte et overblik og en orden over eksperimenterne.

Som bruger

Fordi jeg selv har været med til at sende rigtigt mange eksperimenter ud, forstår jeg formålet. Men som bruger er eksperimenter noget af det mest frustrerende. Da jeg boede i Tyskland brugte jeg banken N26, da de havde de beste digitale produkter. Problemet var bare, at de konstant lavede A/B tests med deres layout. Når jeg skal betale en regning eller overføre penge, så vil jeg meget gerne have, at oplevelsen er nogenlunde den samme hver gang. Hvis jeg kan ordne regninger efter muskelhukommelsen er det endnu bedre. Men hver gang jeg skulle betale en regning, så var menuen ændret, knapperne flyttet rundt eller det var samlet på en helt ny side. Det var ekstremt frustrerende som bruger, men jeg er da sikker på, at der sad en glad product manager derinde.

Det er lidt for nemt at blive fanget bag ideen om, at eksperimenter altid er gode og altid giver mening. At skubbe pilen opad kan se virkelig godt ud internt, men det kan være så frustrerende for brugerne, at de skrider, hvis ikke der er en sammenhæng i brugeroplevelsen.