Het verschil in één zin
Een componentenbibliotheek is code die je kunt importeren. Een design system is een afspraak over hoe je bouwt, waarvan die code een uitkomst is.
Het onderscheid wordt zichtbaar zodra een team iets nodig heeft dat er niet in zit. Bij een bibliotheek bouwt dat team het zelf, want niemand kan zeggen of het erin thuishoort. Bij een systeem is dat wel duidelijk, en is er iemand die beslist. Het verschil zit dus niet in de componenten maar in wie beslist, wat er wel en niet in hoort, wat je mag verwachten en wie je aanspreekt als het stuk is.
Je hebt een design system
Je hebt een componentenbibliotheek
Waarom dit onderscheid ertoe doet
Een bibliotheek levert winst op de dag dat je hem introduceert: twee teams bouwen niet meer allebei een eigen knop. Het probleem komt later. Zonder eigenaar veroudert hij, en teams die iets missen bouwen het lokaal. Na twee jaar dekt die gedeelde map de helft van je UI, met daarnaast een verzameling varianten die niemand overziet. Dan is het geen versneller meer maar een extra plek om rekening mee te houden.
Betere componenten lossen dat niet op. Wie beslist en wat een team mag verwachten wel. Dat is organisatiewerk, geen frontendwerk, en daarom blijft het liggen.
| Componentenbibliotheek | Design system | |
|---|---|---|
| Wat het is | Gedeelde code | Afspraak over hoe je bouwt |
| Eigenaarschap | Impliciet, vaak bij het team dat het maakte | Expliciet, met een naam en tijd |
| Nieuwe behoefte | Team bouwt het zelf, lokaal | Duidelijk of het erin hoort, met een besluit |
| Wijzigingen | Komen aan in de build | Aangekondigd, met migratiepad |
| Ontwerp en code | Twee waarheden | Eén bron, twee verschijningsvormen |
| Succes meten | Aantal componenten | Aandeel van de UI dat eruit komt |
| Wat het oplevert | Eenmalige tijdwinst | Snelheid die blijft, en consistentie |
”Wij zijn te klein voor een design system”
De vraag is niet hoeveel developers je hebt, maar op hoeveel plekken dezelfde beslissing wordt genomen. Twee productteams en een marketingsite zijn al drie plekken waar iemand bepaalt hoe een knop eruitziet, en vanaf twee betaal je voor het verschil.
Wat met je omvang meebeweegt is alleen het apparaat eromheen. Bij drie teams besteedt de eigenaar er een halve dag per week aan en is een besluit over de scope een gesprek; bij tweehonderd teams heb je tiers, service niveaus en een roadmap nodig. Dat apparaat is niet de voorwaarde om te beginnen, de afspraak is dat.
Vier vragen die in tien minuten uitwijzen wat je hebt. Ze gaan geen van alle over code.
Wie beslist of iets in het systeem komt?
Kun je een naam noemen? Zo niet, dan heb je een bibliotheek. Dit is de vraag die het onderscheid maakt, want zonder besluitvormer is er geen systeem maar een verzameling.
Wat gebeurt er als een team iets mist?
Als het antwoord 'dan bouwen ze het zelf' is, groeit je UI buiten het systeem om. Weet een team of iets erin thuishoort en bij wie het dan moet zijn, dan heb je iets dat werkt.
Hoeveel van je UI komt er daadwerkelijk uit?
Niet hoeveel componenten er in zitten, maar welk aandeel van wat gebruikers zien eruit komt. Als niemand dat weet, wordt adoptie een mening en kun je niet sturen.
Wanneer is een component voor het laatst gewijzigd?
Een systeem dat leeft, verandert. Staat alles al een jaar stil, dan is het geen systeem meer maar archief, hoe goed de componenten ook zijn.
Waar je begint
Niet bij meer componenten bouwen, dat is de reflex en het vergroot het probleem. Begin bij eigenaarschap: één naam, met tijd die daadwerkelijk is vrijgemaakt. Bepaal daarna wat je belooft, bijvoorbeeld een kernset van tien componenten die je gegarandeerd onderhoudt en de rest op eigen risico. En meet welk aandeel van je UI nu uit de bibliotheek komt, want zonder nulmeting blijft elke discussie hierover een gevoelskwestie.
Wat er daarna misgaat is voorspelbaar en gaat zelden over techniek. Dat staat in waarom design systems stranden na de lancering.