Waarom je design system faalt (en hoe je het beter opzet)

We bouwen al jaren design systems, en ze falen telkens op dezelfde manier: het systeem wordt gebouwd, het ziet er onberispelijk uit in Figma en dan gebruikt niemand het. Met de componenten is meestal niets mis.

Wat een design system is

Een design system is de gedeelde bron van waarheid voor hoe een product eruitziet, zich gedraagt en gebouwd wordt, plus de afspraken die ervoor zorgen dat iedereen het gebruikt. De componentenbibliotheek en het Figma-bestand zijn daar maar een deel van. Een bruikbaar systeem heeft een paar duidelijke lagen:

• Design tokens: de kleinste beslissingen, één keer benoemd. Kleur, ruimte, typografie, radius, schaduw. Verander een token en het verandert overal tegelijk mee, in Figma en in code, zodat niets uit de pas gaat lopen.
• Componenten: de herbruikbare bouwstenen zoals knoppen, invoervelden, cards en modals. Eén keer gebouwd, standaard toegankelijk, zodat niemand ze op elk scherm net iets slechter opnieuw maakt.
• Patronen: hoe die bouwstenen samenkomen om een terugkerende klus op te lossen, zoals een formulier, een leeg scherm of een afrekenstap. Los ze één keer goed op en elk team stopt met opnieuw beginnen.
• Richtlijnen: de tekst die zegt wanneer je iets gebruikt, wanneer niet en waarom. De meeste systemen slaan dit over, en het is het deel dat bepaalt of iemand de rest vertrouwt.
• Beheer: de afspraken over wie het bezit en hoe het verandert. Zonder die rot het systeem weg zodra het product sneller begint te bewegen dan het kernteam.

Sla je die laatste twee over, dan heb je alleen een map met componenten.

Waarom de meeste design systems falen

Ze falen wanneer ze in isolatie worden gebouwd. Een kernteam verdwijnt drie maanden, komt terug met een gladde bibliotheek en overhandigt die aan designers en developers aan wie nooit is gevraagd wat ze nodig hadden. Het is op papier af en in de praktijk onbruikbaar, omdat adoptie werd behandeld als een lancering in plaats van iets waar je voor ontwerpt.

De tweede manier om te falen is precies andersom. Het systeem gaat live, mensen nemen het over en dan bevriest het. Het product beweegt door, het systeem staat stil en binnen een jaar bouwen teams er weer omheen.

Begin bij het product dat er al is

Ontwerp niet het systeem dat je zou willen hebben. Neem het product dat nu live staat onder de loep. Leg elke knop, elk invoerveld en elke card naast elkaar en je vindt elf tinten grijs en zes knopstijlen die allemaal dezelfde hadden moeten zijn. Die rommel is je backlog, en hij onderbouwt het systeem beter dan welke slide ook.

Systematiseer eerst wat zich herhaalt

Probeer niet alles tegelijk te dekken. De waarde zit in de onderdelen die je team elke dag pakt, dus bouw die eerst en bouw ze goed:

• De handvol componenten op bijna elk scherm: knoppen, invoervelden, links, cards.
• De tokens eronder, zodat een kleur- of ruimtewijziging één aanpassing is in plaats van vijftig.
• De twee of drie patronen die het product dragen, zoals het belangrijkste formulier en de primaire lay-out.

Lever dat op, zorg dat het gebruikt wordt en bouw de rest pas als er echt om gevraagd wordt. Een systeem dat zich in week twee terugverdient, verdient de ruimte om te groeien.

Schrijf op waarom

Iedereen kan zien hoe een component eruitziet. Wat ze niet kunnen zien is wanneer je het gebruikt, wanneer je naar iets anders grijpt en waarom het überhaupt bestaat. Zonder die context verliezen mensen hun vertrouwen in het systeem en gaan ze het stilletjes omzeilen. Schrijf het dus op naast het component, niet in een wiki die niemand opent.

Maak bijdragen makkelijk

Een systeem dat alleen het kernteam kan aanraken zal altijd achterlopen op het product, en een systeem dat achterloopt raakt in onbruik. Geef elk team een duidelijke manier om een component voor te stellen, een gat te melden of een bug te fixen. Een bijdrage betekent dat het systeem werkt, dus behandel hem ook zo.

Geef het een eigenaar

Iemand moet verantwoordelijk zijn voor het systeem zoals iemand verantwoordelijk is voor het product. Dat is een persoon of klein team dat beoordeelt wat er binnenkomt, de tekst eerlijk houdt en nee zegt wanneer een eenmalig geval er niet in hoort. Een commissie die één keer per maand vergadert, kan dat niet. Zonder eigenaar gaat een systeem zelden zichtbaar kapot; het klopt alleen steeds minder met het product.

Hoe je weet dat het werkt

Het aantal componenten zegt weinig. Een systeem dat werkt, zit niet in de weg:

• Designers pakken een bestaand component voordat ze een nieuw ontwerpen.
• Developers leveren een scherm sneller op omdat de onderdelen er al zijn en al toegankelijk zijn.
• Nieuwe mensen vinden het antwoord in de tekst in plaats van het in de chat te vragen.
• Het gat tussen wat in Figma zit en wat in productie staat wordt steeds kleiner.

Kom je daar, dan onderhoud je het systeem niet meer als apart project; zo wordt het product gewoon gebouwd.