Teambalans

Nog niet zo lang geleden waren managers en recruiters allemaal op zoek naar die schaarse rockstar-ninja designers. Op zoek naar unicorn designers met uitmuntende vaardigheden en adembenemend CV? De superhelden designers zouden eindelijk de business in beweging brengen en resultaten behalen. De waarheid is dat ze dat inderdaad zouden kunnen, maar wel tegen een hoge prijs: een verziekte teamgeest.

De meest inspirerende ontwerpers zijn vaak T-shaped. Op een lijn van pure generalist naar specialist, ligt de T-shaped ontwerper in het midden. Hij valt op door zijn goede designkwaliteiten en uitmuntende sociale vaardigheden .

In mijn ervaring zijn de beste teams evenwichtig en divers. In zulke teams wordt iedereen gerespecteerd, gestimuleerd en gelijk behandeld. Een gezond team is zo veel sterker dan een team dat is samengesteld rondom die ene zeer getalenteerde unicorn. Een team weet zoveel meer dan een individu. Uiteindelijk wordt de teamgeest altijd geschaad als er altijd eerst weer naar de rockstar-ninja super designer wordt gekeken. Dat vertraagd en heeft een negatieve invloed op de motivatie en de kwaliteit van het werk.

Een goed ontwerp weerspiegelt het karakter van de mensen die eraan werken. We hebben vaak de neiging om te geloven dat ons werk draait om het schuiven van lijnen in Sketch of het verfijnen van prototypes in Invision, maar goed ontwerp is ook een soepele flow tussen teams. Teams die echt geven om hun werk en de gebruikers van het product.

Voor een goede teambalans moeten teamleden zich veilig voelen om zich uit te spreken indien er iets niet goed gaat. Of wanneer user stories de verkeerde kant op lijken te gaan; in tegenspraak zijn met waar ze in geloven. Teamleden moeten de vrijheid ervaren om hun werk te doen op een manier die ze zelf het best vinden. Dat is de ware kracht van het team: de omgeving waarin iedereen zichzelf kan zijn. Om zijn mening te geven. Om “Nee” te zeggen. Om een nieuw, misschien wel vreemd idee voor te stellen. Maar ook om je eigen groeipad te kiezen.

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.