Product-gericht innoveren

Ik ben opgeleid in Delft tot Industrieel Ontwerper. Ik starte mijn carrière als Interaction Designer (bij Informaat in Baarn). Daarna vervolgde ik mijn carrière als User Experience Designer (bij bol.com in Utrecht). De laatste twee jaar hebben we bij bol.com onze manier van werken veranderd; we streven product gerichte groei na. En ik noem mezelf nu Product designer.

Een goed product is altijd het geheim achter succesvol bedrijf geweest. In de jaren ’80 en ’90 was dat de verantwoordelijkheid van verkopers. Als je toen een nieuw product wilde kopen, ging je naar de winkel en sprak je met een verkoper. Als je geluk had, was diegene deskundig en geïnteresseerd en hielp hij je het beste product voor jou te kiezen. En toen kwam het internet: digital marketing professionals kregen steeds meer mogelijkheden om klantgedrag en verkoopresultaten te meten en bij te sturen.

En tegenwoordig willen we niet meer doorlopend met verkopers praten of ons laten verleiden door marketingcampagnes. Bedrijven moeten hun marketing-, verkoop- en service-strategieën aanpassen aan deze tijd van e-commerce en social media.

In elke organisatie werken verschillende teams – marketing, verkoop, klantenservice, design, engineering. Oorspronkelijk werkten die elk op hun eigen manier. Product-gericht werken brengt deze teams samen. Het idee is, dat hun gecombineerde krachten zorgen voor een verbeterde gebruikerservaring.

In nauwe samenwerking tussen productontwikkeling en marketing, wordt doorlopend feedback van klanten gebruikt om het product te verbeteren en aan te passen aan de veranderende behoeften en verwachtingen van de markt. Het resultaat is een duurzame groei van het bedrijf en loyale klanten.

Product-gericht werken is de democratisering van het product. En zoals in elke democratie vereist product-gerichte groei dat de traditionele managers het besluitvormingsproces openstellen voor een grotere, meer diverse groep stakeholders. En natuurlijk leidt dit tot moeilijkere en complexere discussies. Maar uiteindelijk leiden deze discussies tot betere, meer innovatieve producten.

Het afgelopen jaar heb ik meegedaan aan een pilot om systematisch te gaan werken aan “Product Discovery”. In design thinking kennen we de double diamond. In de eerste diamant probeer je uit te vinden welk probleem het meest belangrijk is om op te lossen. De zoektocht naar “Opportunities” is een divergerende fase. Je interviewt klanten en stakeholders om te leren wat hen bezighoudt, welke behoefte ze hebben en tegen welke problemen ze aanlopen.

Voor onze Product Discovery pilot gebruiken we de methoden en technieken van Teresa Torres. In haar boek Continuous Discovery Habits pleit ze voor wekelijkse gesprekken met klanten. Dat is ons nog niet gelukt – in mijn team zijn we ook nog steeds erg druk met ontwerpen en bouwen van software – in mijn product spreken we elke twee weken met vijf klanten.

We vragen klanten naar recente ervaringen; want dat is de meest betrouwbare informatie. In het tweede deel van zo’n interview proberen we aannames te valideren waar we de afgelopen weken tegenaan liepen. Met continuous interviewing hebben we elke twee weken een moment op onze eigen aannames en vooroordelen te valideren bij klanten. Na vijf gesprekken zien we een patroon ontstaan. Misschien is onze conclusie dan nog niet geheel betrouwbaar, maar dan kunnen we over twee weken er nog wat dieper induiken.

Na elk gesprek met een klant, zien we verschillen tussen hoe wij over het product denken en hoe onze klanten dat doen. Het is hard werken om klanten beter te leren kennen; en zo veel mogelijk beslissingen te maken met input van klanten.

Goede managers vragen productteams om te werken aan een specifiek doel: een “outcome”. Vaak is dat een financieel resultaat, zoals hogere omzet, meer klanten of hogere winst. Of door middel van bedrijfsstrategieën, zoals het vergroten van marktaandeel of het uitbreiden naar andere landen. Dit noemen we de strategische context waarbinnen een product team werkt.

Als productteam moeten wij dat resultaat vertalen in iets wat wij kunnen beïnvloeden. Een Key Result meet hoe goed ons product bijdraagt aan de gevraagde Outcome. Het meet een bepaald klantgedrag dat we in ons product kunnen waarnemen, waarvan wij vermoeden dat het een bijdrage levert aan ons productresultaat. Dit zorg bij ons nog vaak voor ingewikkelde discussies. Discussies over definities en logica; wat kun je direct meten en hoe weten we zeker dat dat op lange termijn daadwerkelijk bijdraagt aan wat we willen bereiken (ons Key Result)?

We weten dat digitale producten nooit klaar zijn. Het is niet zo, dat als je een project (of feature) hebt afgerond, het product af is. De concurrentie zit ook niet stil. Om van een projectmentaliteit naar een productmentaliteit te gaan, moeten we stoppen met denken in features. In plaats daarvan moeten we ons afvragen: Welke impact hebben de wijzigingen gehad?

De discussie over ‘wat weten we al wel’ en ‘wat weten we nog niet’ is een heel essentiële in Product Discovery. Om daar structuur aan te geven gebruiken we de Opportunity Tree zoals Teressa Torres die beschrijft. Zij verwijst naar deze uitspraak van Barbara Tversky.

“Structure is complicated. It gets done, undone, and redone.”

Als we klanten interviewen, vertellen ze ons over talloze ervaringen, pijnpunten en wensen. Hoe beslissen we welke kansen het belangrijkst zijn? Hoe weten we welke Opportunity we nu mee moeten beginnen en welke opportunities we naar morgen kunnen doorschuiven?

Teresa Torres zegt dat het moeilijk is deze vraag te beantwoorden als we niet eerst een inventarisatie maken van alle opportunities. En dat is de opportunity tree: een boomstructuur die start bij de outcome en dan vertakt in kansen en pijnpunten.

Door de opportunity space in kaart te brengen geven we structuur aan het ongestructureerde probleem van het bereiken van het gewenste resultaat.

En als we dan een overzicht hebben van alle opportunities, dan volgt de divergerende fase. We moeten het effect van de ene kans vergelijken met het effect van een andere kans. Want wat je wil is doelbewust en systematisch zoeken naar de kans met het grootste effect!

Helaas zijn de meeste opportunity spaces te complex om als een platte lijst te overzien. De boomstructuur helpt ons de complexiteit van de kansenruimte te visualiseren en te begrijpen. Boomstructuren geven twee belangrijke relaties weer: ouder-kind relaties en broer-zus relaties. Beide helpen ons de rommelige opportunity space te begrijpen. Als we leren denken in boomstructuren, helpt dat ons grote, onoplosbare problemen te ontleden in een reeks kleinere, beter oplosbare problemen.

Een kleine probleem aanpakken lost misschien niet gelijk het hele hoofdprobleem op, maar wel een deel daarvan.

Lean UX

Als je we succesvol willen blijven, moet we blijven innoveren. Innoveren is risicovol. Slechts een klein deel van nieuw ontwikkelde producten is succesvol op de markt. En hoe goed het product ook is, klantgedrag is onvoorspelbaar. Dus, hoe kunnen we onze kansen op succes vergroten? Ons antwoord is Lean UX.

Lean UX haalde inspiratie uit de succesvolle werkwijze van IT-teams. Die werken agile: ze werken in multidisciplinaire teams, autonoom aan kleine brokjes werk (user stories). Dat doen ze in korte sprints van twee weken.

In een traditioneel UX project starten we met verzamelen van eisen en wensen. Het doel van zo’n project is om aan het eind een zo gedetailleerd mogelijke ontwerpdocumentatie op te leveren aan de ontwikkelaars.

Bij een Lean UX project doen we dat anders: we gaan vooral op zoek naar productoptimalisaties voor eindgebruikers. We doen dit met het hele team: designers, business analisten, stakeholders en ontwikkelaars samen. We schrijven geen volledige ontwerpdocumentatie, maar proberen zoveel mogelijk samen te werken om een goed product te maken.

Als ik met collega’s praat over ons design proces, dan hoor ik regelmatig misvattingen over Lean UX. Lean UX is geen recept voor succes, het is geen stappenplan voor innovatie en het is ook geen plan van aanpak voor een ontwikkelproject.

LEAN UX is een manier van denken en leven die een cultuur van continu verbeteren creëert én in stand houdt. Het is een ‘way of life’ voor de hele organisatie, van copy writer tot directeur. Uitgangspunt is dat we waarde voor de klant willen vergroten door het elimineren van ‘afval’ in ons werkproces. In het proces ligt minder nadruk op deliverables en meer focus op de daadwerkelijke experiences die we ontwerpen. Ik zie dat veel teams moeite hebben om Lean UX te werken. In dit artikel hoop ik wat handvatten te kunnen geven om met Lean UX te starten.

Vorig jaar was ons ontwikkelproces nog heel erg waterval. Het ging ongeveer zo: Een business developer of category manager bedacht een plan en onderzocht de kansen daarvoor in de markt. Dan ging een business analist daarmee aan de slag en briefde een designer. De interactie designer bedacht een concept en maakte een wireframe. De interface designer detailleerde het design tot volwaardig design. De business analist werkte dit weer uit tot user stories voor het IT-team. Elke rol maakte z’n eigen deliverable. Bij elke overdracht ging veel kennis verloren. En pas als het product op de markt was gebracht, vertelde de omzetcijfers of we succesvol waren.

Niemand was hier gelukkig mee, dus we moesten iets veranderen. En toen kwam Lean UX op ons pad.

Stop making a big design up front 
Instead focus on experimenting in small batches andTest actual user experiences and
strive on learning by doing

We reorganiseerde de afdeling: we creëerde cross functionele autonome teams rondom een onderwerp. We zetten Business en IT bij elkaar. Alle leden van het team samen bij elkaar aan een blok, zodat ze doorlopend overleggen. Met praten, praten, praten, ideeën delen en elkaar feedback geven, krijg we gemeenschappelijk begrip over de uitdagingen waar we als team voor staan.

Bij aanvang hebben we ons wel de vraag gesteld: wat is er nodig om met Lean UX te kunnen starten? We begonnen met het samenstellen van multi-disciplinair teams van een business analist, een ux designer en een paar (frontend) ontwikkelaars. We gaven hen een doelstelling en we gaven hen het vertrouwen dat ze geheel autonoom, samen binnen de gestelde kaders het beste resultaat zouden halen.

Moeten alle teams Lean UX gaan werken? Nee, er zijn wel randvoorwaarden: allereerst moet het team het vertrouwen hebben van de organisatie, dat zij samen het best weten hoe ze de meest waarde voor de klant kunnen realiseren. Daarnaast moet het team de mogelijkheden hebben om regelmatig z’n ideeën en prestaties te kunnen toetsen met klanten. Voor Lean UX is leren wat werkt en wat waarde oplevert voor klanten belangrijker dan korte termijn resultaten (zoals directe omzet- of conversiestijging). Als het team gezamenlijk kennis vergaard, dan komen de resultaten vanzelf. 

Dus hoe weten we wat de klant waardevol vindt en wat niet? De (verbeter)ideeën krijg we door regelmatig contact te hebben met klanten. Ieder teamlid moet regelmatig contact hebben met echte (onbevooroordeelde) eindgebruikers. We doen op verschillende manier onderzoek. Voor mij is de belangrijkste de GOOB-sessie. Get.Out.Of the.Building en observeer gebruikers terwijl ze een product gebruiken. We doen onderzoeken met concurrerende websites, met prototypes en met bèta-producten. Zo leren we wat klanten belangrijk vinden, wat werkt, waar bugs zitten, waar knelpunten zitten en waar ze in de dagelijkse praktijk problemen mee ondervinden.

Na het verkennende onderzoek maken we onze aannames expliciet, stellen we hypotheses op en gaan we brainstormen voor experimenten: hoe te toetsen of onze aannames kloppen.

Misschien denk je, klinkt goed, maar hoe ziet een typisch Lean UX project er nu uit? Wat moet ik doen? Onderstaande tijdlijn kan je hierbij misschien helpen. In meer of mindere mate kun je in elk project de volgende stappen herkennen:

  1. Leer van je (potentiële) klanten: analyseer data, observeer en interview gebruikers. Stop: dit moet je ook niet overdrijven. Iets maken (en testen) is veel efficiënter dan blijven analyseren.
  2. Doe een aanname: hoe kan ik extra waarde creëren voor de klant. Aannames verzin je het best in een workshop met je team. Je maakt het probleem concreet en gaat dan met het team brainstormen voor oplossingen om dat probleem op te lossen. In dit proces verzin je de antwoorden op de onderliggende vragen. Dat zijn je aannames.
  3. Bedenk, schets samen met het hele team een oplossing
  4. Deel het idee, valideer met andere teams en stakeholders
  5. Maak een prototype, of iets waarmee je de aanname kan toetsen (zonder al teveel investeringen te doen)
  6. Test met eindgebruikers. Get Out Of the Building: observeer je gebruiker als die met je prototype aan de gang gaan.
  7. Verbeter je prototype met de inzichten uit het gebruik van de eindgebruiker
  8. Is je prototype goed genoeg: bouw een eerste kleinschalige productieversie. Zet deze live (bij voorkeur in een ab-test).
  9. Valideer of je product de aanname uit stap 2 bevestigd.
  10. Is je oplossing een succes? Bouw dan een schaalbare versie voor het grote publiek.
  11. Maak de klantervaring compleet: wellicht heb je zaken achter wegen gelaten, omdat je eerst alleen je aanname wilde toetsen. Maar als je het echte product neerzet, wil je misschien net iets meer doen, met goede kwaliteit en volgens standaarden ontwikkelen, om de klant verwachtingen te overtreffen. 

Let op: dit is geen recept of stappenplan. In elke fase moet je heel kritisch kijken waar je staat en wat je nodig hebt om een volgende stap te kunnen zetten. Blijkt je prototype niet te werken? Pas het aan en test opnieuw! Kun je je aanname niet bevestigen? Bedenk een nieuwe oplossing. Als de gekozen oplossing geen succes was, is dat geen falen, maar een leermoment.

Lean UX draait om productoptimalisaties en dat kan leiden tot veel adhoc oplossingen. Of zelfs concurrerende oplossingen. We moeten niet vergeten om regelmatig uit te zoomen en het bedrijfsdoel in het oog te houden. Wat verwacht de klant van ons als geheel? Hoe verhoudt onze feature zich tot die van de andere teams? Bieden we nog een consistente klantervaring? Verzinnen we nu iets nieuws terwijl er al een succesvolle oplossing voor is (elders binnen het bedrijf)? 

Voordat je als team start met optimaliseren of bouwen aan een nieuw thema is het goed om even stil te staan bij de gezamenlijke visie en de langere termijn doelen. Na stap 1. van de tijdlijn ga je samen in een workshop de XD Strategie bepalen. Verzin gezamenlijk een tagline, wat gaan jullie veranderen en wat zijn jullie ontwerpprincipes. Hang jullie XD Strategie op de muur en laat ‘m reviewen door andere teams en stakeholders. Een ander belangrijk element is de gezamenlijke visuele identiteit. Om te voorkomen dat elk team zijn eigen stijl gaat ontwikkelen en we daarmee:

  • heel veel dubbel werk doen;
  • een inconsistente en rommelige web site krijgen.

De oplossing licht in een gezamenlijk design systeem. Een design system bestaat uit de gezamenlijke design standaarden en design principes samen in een toolkit (UI patronen, Sketch bibliotheek en code componenten) om deze standaarden makkelijk toe te passen. Dit vraagt om een vorm van DesignOps. We werken dan in drie parallelle tracks: één track waarin strategie en standaarden worden bepaald. Eén track waarin we experimenteren om te leren wat de meeste waarde oplevert. En één track waarin we de oplossing implementeren op een schaalbare manier.

Tri-track agile (volgens InVision)

Conclusie

De wens om Lean UX te gaan werken, vraagt om een cultuuromslag. Niet alleen het innovatieteam moet anders gaan denken en werken, maar ook het management en de stakeholders. Maar Lean UX past bij mij, omdat het datagedreven en klantgericht wil ondernemen. Lean UX vraagt ondernemerschap van het team. En elke medewerker kan het verschil maken!

Oorsprong

Ik ben geboren in de omgeving van Amsterdam. Mijn jonge jaren heb ik doorgebracht in Bemmel en Arnhem.

Na het vwo heb ik Industrieel Ontwerpen gestudeerd aan de TU in Delft. Daar leerde ik het ontwerpersvak en het belang om de gebruiker daarbij te betrekken.

In 1996 ben ik afgestudeerd bij de vakgroep Ergonomie op een navigatietool voor binnenvaartschippers.