Productgericht innoveren

Ik ben opgeleid als industrieel ontwerper in Delft. Mijn carrière begon als interaction designer bij Informaat in Baarn. Daarna groeide ik door tot user experience designer bij bol.com in Utrecht. De laatste twee jaar zijn we bij bol.com anders gaan werken: we streven nu naar productgerichte groei. Sindsdien noem ik mezelf product designer.

Een goed product is de sleutel tot elk succesvol bedrijf. In de jaren ’80 en ’90 lag die verantwoordelijkheid vooral bij de verkopers. Wilde je een nieuw product kopen, dan ging je naar de winkel en sprak je met een verkoper. Met een beetje geluk was die deskundig en geïnteresseerd, en hielp hij je het beste product te kiezen.

Toen kwam het internet. Digital marketing-professionals kregen steeds meer tools om klantgedrag en verkoopresultaten te meten en te beïnvloeden.

Maar tegenwoordig willen klanten geen verkooppraatjes meer. Ze verwachten dat bedrijven hun marketing-, verkoop- en service-strategieën aanpassen aan een tijdperk van e-commerce en social m

Productgericht werken is in feite de democratisering van het product. Zoals in elke democratie vraagt dit om een opener besluitvormingsproces. Managers moeten ruimte maken voor een bredere, meer diverse groep stakeholders. Dat leidt tot meer complexe discussies — maar juist die gesprekken zorgen voor betere, innovatievere producten.

Systematisch ontdekken: Product Discovery

In 2023 nam ik deel aan een pilot om systematischer aan Product Discovery te werken. Design thinking kent de ‘double diamond’: in de eerste diamant onderzoek je welk probleem het belangrijkst is om op te lossen. De zoektocht naar zogeheten opportunities is een divergerende fase, waarin je klanten en stakeholders interviewt om hun behoeften, zorgen en frustraties te begrijpen.

Voor deze pilot gebruiken we de aanpak van Teresa Torres. In haar boek Continuous Discovery Habits pleit zij voor wekelijkse klantgesprekken. Dat is ons nog niet helemaal gelukt — in mijn team zijn we nog volop bezig met het ontwerpen en bouwen van software — maar we spreken elke twee weken met vijf klanten.

Continuous Interviewing

Een belangrijk onderdeel van de aanpak van Teresa Torres is continuous interviewing. In ons team doen we dat door elke week vijf klanten uit te nodigen voor korte gesprekken. Elk gesprek duurt twintig minuten. Daarna schuift dezelfde klant door naar een ander team, dat ook twintig minuten met hem of haar spreekt. Zo combineren we efficiëntie met diepgang en kunnen meerdere teams waardevolle inzichten opdoen.

In onze gesprekken willen we vooral begrijpen waar onze klanten behoefte aan hebben. Meestal gebruiken we een open format, bijvoorbeeld: “Kun je me vertellen over een recente ervaring waarin je… [onderwerp]”. Door klanten te laten vertellen over echte gebeurtenissen, krijgen we betrouwbare informatie over hun gedrag, wensen en frustraties.

Doordat we deze gesprekken wekelijks voeren, bouwen we stapsgewijs kennis op over wat er leeft bij onze klanten. We krijgen steeds meer zicht op de onderliggende problemen, behoeften en drijfveren. Die kennis vormt een stevige basis voor het nemen van betere productbeslissingen.

Wat we elke keer weer zien: klanten denken vaak anders over het product dan wijzelf. Het kost moeite om die verschillen te begrijpen — maar hoe beter we onze klanten leren kennen, hoe meer beslissingen we kunnen nemen op basis van hun input.

Werken aan outcomes

Goede managers vragen productteams om te werken aan een specifiek doel: een gewenste uitkomst, of outcome. Vaak is dat een bedrijfsdoel zoals meer omzet, meer klanten, of uitbreiding naar nieuwe markten.

Voor het productteam betekent dit: vertalen naar iets wat we daadwerkelijk kunnen beïnvloeden. Dat doen we met een Key Result — een meetbare gedragsverandering bij de klant waarvan we vermoeden dat die bijdraagt aan de gewenste outcome.

Dit leidt in de praktijk vaak tot pittige discussies. Wat kunnen we meten? Hoe weten we zeker dat dat gedrag op de lange termijn effect heeft? En is onze redenering logisch onderbouwd?

Impact boven features

Digitale producten zijn nooit af. Ook als je een project of feature oplevert, is dat slechts een tussenstap. De concurrentie blijft immers ook doorontwikkelen.

Om de stap te maken van een projectmentaliteit naar een productmentaliteit, moeten we stoppen met denken in features. In plaats daarvan stellen we de vraag: Welke impact hebben onze wijzigingen gehad?

Structuur aanbrengen in onzekerheid

Een cruciale vraag binnen Product Discovery is: Wat weten we al, en wat weten we nog niet? Om daar structuur aan te geven gebruiken we de Opportunity Tree, zoals Teresa Torres die beschrijft. Zij verwijst naar Barbara Tversky, die zei:

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

In klantinterviews horen we tientallen ervaringen, pijnpunten en wensen. Maar hoe beslis je welke kansen het belangrijkst zijn? Welke pak je nu op — en welke later?

Volgens Teresa Torres is het onmogelijk om die vraag goed te beantwoorden zonder eerst een volledig overzicht te maken van de kansen. Dat overzicht noemen we de opportunity tree: een boomstructuur die begint bij de gewenste outcome en vertakt naar concrete problemen, wensen en kansen.

Door deze ‘opportunity space’ in kaart te brengen, brengen we structuur aan in een ongestructureerd probleem. Vervolgens vergelijken we de mogelijke impact van verschillende kansen. Wat is het meest veelbelovend? Zo zoeken we doelgericht naar de opportunity met het grootste effect.

De meeste opportunity spaces zijn te complex om als platte lijst te overzien. De boomstructuur helpt ons die complexiteit te visualiseren en begrijpen. Ze toont twee essentiële relaties: ouder-kind (oorzaak-gevolg) en broer-zus (alternatieven naast elkaar). Als we leren denken in boomstructuren, kunnen we grote, onoplosbare problemen opdelen in kleinere, hanteerbare stappen.

Een klein probleem oplossen lost misschien niet meteen het hele hoofdprobleem op — maar wel een essentieel deel ervan.

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.