Experiment driven design

In mijn vorige artikel pleitte ik voor meer ruimte om te leren binnen productteams. Dit artikel geeft richting aan de praktische implementatie.

Sturen op meetbare uitkomsten

Als designer, developer en productmanager willen we allemaal hetzelfde, producten maken die mensen graag gebruiken. Tijdens ons werk doen we dagelijks honderden aannames. Aannames ten aanzien van de gebruiker, zijn doelen en frustraties. We raadplegen bronnen als analytics en gaan langs bij customer support. Tot slot is daar de business met nieuwe ideeën en zo voeden we het monster, de product backlog.

Op basis van al deze input worden userstories geschreven, geprioriteerd en geïmplementeerd. Sprint na sprint na sprint. Userstories zijn uitermate geschikt als bron van discussie en voor het inschatten van werkzaamheden. Wat we niet vastleggen in stories is de beoogde meetbare verbetering die we verwachten. Hierdoor is het enorm moeilijk om achteraf te bepalen of we succesvol zijn geweest in het halen van onze user- en businessgoals.

Testkaarten, leren door te experimenten

Voor het inzetten van experimenten in teams maak ik gebruik van de test- en leerkaarten van Alex Osterwalder. De testkaart helpt je om een aanname te formuleren en dwingt je om de volgende dingen expliciet te maken;

  • Hypothese, wat moet waar zijn om de aanname te valideren?
  • Oplossing, hoe ga je testen of je aanname waar of onwaar is?
  • Meten, wat ga je meten om de aanname te valideren?
  • Criteria, wanneer zijn we succesvol, wat is de drempel?

Laten we beginnen bij het begin. Voordat we na kunnen denken over meetbare uitkomsten moeten we goed kijken naar onze aannames. Om een aanname te kunnen testen zijn er een aantal randvoorwaarden waar je rekening mee moet houden.

Randvoorwaarden om te kunnen testen

De hypothese

Goede aannames (of hypotheses) opstellen is moeilijk voor teams. De meeste mensen hebben meer oog voor oplossingen dan voor problemen. Dit leidt tot te veel features en producten met te weinig engagement. Dit is belangrijk, omdat je op een goede manier wilt kunnen valideren wat je aan het doen bent.

Een goede hypothese / aanname bevat de volgende bouwstenen.

Wij geloven dat [doelgroep] zal [actie] om [reden]

Ieder key-element in deze zin is een variabele voor je experiment en een mogelijke reden voor falen. Het is belangrijk dat je de zin begint met ‘wij geloven dat’, omdat je direct in de juiste mindset zit.

Voorbeeld:

Wij geloven dat mensen die graag fietsen eerder een fietsarrangement boeken als ze zien dat veel andere mensen hetzelfde arrangement hebben geboekt.

De test

Nu gaan we nadenken over de oplossing die we voor ogen hebben. Hoe ziet deze er uit en bovenal, hoe gaan we die testen? Probeer je oplossing te beginnen met:

Om dat te bewijzen zullen we…

Voorbeeld:

Om dat te bewijzen maken we een widget met de meest trending arrangementen.

Meten

Welk cijfer gaan we beïnvloeden met onze test? Hierbij is het belangrijk dat je duidelijk voor ogen hebt wat de baseline nu is. Als je geen betrouwbare data hebt zorg dan eerst dat deze er komt voordat je het experiment start. Zonder nulmeting geen experiment.

Voorbeeld:

Het gemiddeld aantal bekeken arrangementen tot een boeking.

Criteria

Wat is een acceptabele verbetering om te kunnen zeggen dat het experiment geslaagd is? Het is niet eenvoudig om een realistisch getal te plakken op een getal dat voldoende bewijs levert voor onze aanname.

Voorbeeld

Aantal bekeken arrangementen tot een boeking verminderen met 20%.

In de praktijk zul je zien dat een enkel experiment niet altijd voldoende is om een aanname te valideren op waar of onwaar. Dit is niet erg, ieder experiment dat je doet leert je meer over mogelijke vervolgstappen dan het simpelweg afwerken van userstories. Door bezig te zijn met uitkomsten in plaats van oplossingen zorg je dat het team gefocust is op vooruitgang.