3 manieren om UX design te organiseren binnen agile development

Hoe kun je UX designers het beste ‘adopteren’ in jouw product teams? Als digital product manager heb je vast al ooit met deze vraag in je maag gezeten. Inspirerende organisatiemodellen zoals het Spotify Model laten ons agile hart sneller kloppen, terwijl we in de praktijk nog vaak worstelen in een stugge top down hiërarchie.

In organisaties zie je veelal dat SCRUM product teams als eerste ontstaan binnen software development. Peinzend over hoe een dergelijke afdeling moet werken, worden er agile proefballonnen opgelaten. Op het moment dat de agile methodiek is bewezen, en een framework zoals SCRUM is geïmplementeerd, dan zie je één of meerdere teams die bestaan uit developers, testers en business analisten. Met veel geluk heb je een architect ‘on the side’.

Bij front-end development ben je afhankelijk van een user experience of web designer. Maar hoe manage je de samenwerking tussen het product team en deze designer? Maak je hem of haar vast onderdeel van het team of hou je deze persoon buiten de spreekwoordelijke deur? In dit blogartikel zet ik de verschillende opties voor je uiteen.

1. Gescheiden en per opdracht toegewezen

Organisaties waar designers zijn ondergebracht in een apart team of afdeling werken initieel vaak op projectbasis. Designers worden per project (of opdracht) toegewezen om een product team te voorzien van onderzoek, advies, wireframes, prototypes, mockups en webdesigns. Hiermee werkt een dergelijke design afdeling als een gedeeld “resource center” waar middels een procedure opdrachten worden aangevraagd, getoetst en toegewezen. Afhankelijk van de werkwijze beheert een dergelijk ontwerpteam zijn eigen (afzonderlijke) backlog.

Voordelen van deze aanpak

Bevordert interne kennisdeling binnen ontwerpteam;
Geeft de mogelijkheid om de juiste expertises flexibeler en efficiënter toe te wijzen aan projecten en opdrachten;
Biedt meer ruimte voor gezamenlijk UX onderzoeken en strategievorming;
Geeft ontwerpers meer afwisseling (en uitdaging) qua opdrachten;
Leidt tot een meer consistente output van het ontwerpteam;
Maakt UX een zichtbaarder expertisegebied.

Nadelen van deze aanpak

Leidt vaak tot vertraging omdat een “waterval”-werkwijze ontstaat en planningen op elkaar moeten worden afgestemd;
Designers staan verder weg van het product team (voelen zich minder onderdeel van);
Ze zijn maar deels betrokken en hebben minder zicht op het eindproduct;
Ze voelen zich minder (of niet) verantwoordelijk voor de uiteindelijke oplevering van het product team;

2. Geïntegreerd en 100% toegewezen

De tegenovergestelde manier van organisatie is een situatie waarbij de designers volledig zijn opgenomen in het product team. Elk product team heeft haar eigen ontwerper toegewezen. UX werkzaamheden worden opgenomen in de backlog en volgen dus ook het reguliere prioritering-, analyse- en refinement proces. De product owner is in controle over UX werkzaamheden. In een dergelijke setup rouleren ontwerpers vaak periodiek (om de 12 maanden bijvoorbeeld) tussen de verschillende product teams. Dit wordt gedaan om een gezonde afwisseling te garanderen.

Voordelen van deze aanpak

Designers zijn geïntegreerd in de gehele productcyclus (van ideation tot oplevering) en voelen zich daardoor meer betrokken en verantwoordelijk voor het eindproduct;
Ze verwerven een sterkere affiniteit met techniek en MVP / lean aanpak;
Kwalitatievere en effectievere eindproducten door meer inbreng van UX tijdens alle iteratieslagen;
Opschalen is eenvoudiger: een extra team betekent een extra designer;

Nadelen van deze aanpak

Gevaar voor teveel focus op leveren, wat ten koste kan gaan van onderzoek en kwaliteit;
De totale gebruikerservaring wordt snel gefragmenteerd en inconsistent;
Eén ontwerper per team kan zich op termijn geïsoleerd gaan voelen (/onvoldoende mogelijkheid om kennis en ervaring te delen met mede-ontwerpers);

3. Hybride UX organisatie

Tijdens de introductie benoemde ik al het Spotify model. Dit model is “een mensgerichte, autonome benadering voor agile opschaling die het belang van cultuur en het totale netwerk benadrukt”. Het heeft Spotify en andere organisaties geholpen om innovatie en productiviteit te vergroten door zich te concentreren op autonomie, communicatie, verantwoordelijkheid en kwaliteit. Maar wat is de link met dit artikel?

Leren van Spotify

Een onderdeel van het Spotify Model is perfect toepasbaar op het organiseren van UX resources in product teams. Spotify werkt met zogenaamde “squads”. Met zoals bij een SCRUM team richt een squad zich op één feature gebied. Het grote verschil is dat een squad zelf bepaalt welke agile methodologie / framework (zoals SCRUM en Kanban) ze wil gebruiken.

Hoewel squads autonoom zijn, is het belangrijk dat specialisten (zoals designers) zich afstemmen op best practices. Zogenoemde “chapters” vormen de familie die elke specialist heeft en helpen om normen in een discipline te handhaven. Chapters worden doorgaans geleid door een senior specialist, die ook de manager kan zijn van de teamleden in dat Chapter.

Terug naar ons vraagstuk. Om een goede mix te krijgen tussen opties 1 en 2 uit dit artikel, kunnen je leren van het Spotify Model.

Hybride model

In ons voorbeeld kan de organisatie als volgt worden opgezet:

Meer generalistische UX designers (afkorting “UX”) zijn verdeeld over de verschillende product teams / squads. Op basis van het feature gebied (en diens behoefte aan UX) besluit je om één ontwerper toe te kennen of meerdere. Meer gespecialiseerde designers, denk hierbij aan senior designers (“SUX”) of usability onderzoekers (“UR”), zijn in een afzonderlijk cluster geplaatst. Deze specialisten bieden ondersteuning aan de product teams. De volledige UX discipline vormt samen de UX chapter.

Op deze wijze behoud je een goede cohesie binnen de UX discipline, maar zorg je wel dat de verschillende generalistische UX designers meer betrokken en verantwoordelijk zijn bij de eindproducten die de product teams opleveren.