Het patroon
Een design system wordt gelanceerd met een presentatie, een documentatiesite en enthousiasme. Zes maanden later gebruikt een deel van de teams het, een deel half, en een deel is stilletjes iets eigens gaan bouwen. Niemand kan zeggen welk deel wat is.
De discussie gaat dan over de componenten: te beperkt, te rigide, net niet passend. Zelden is dat de oorzaak. Het gaat mis op wat ervoor komt, en dat zijn organisatievragen: waarvoor is het systeem bedoeld, wie gaat erover, en wat mag een team ervan verwachten.
Zes redenen waarom een design system na de lancering vastloopt. Geen daarvan is een technische.
Het is van iedereen, dus van niemand
Het systeem wordt beheerd door een team dat het erbij doet, naast hun eigenlijke werk. Bij drukte valt het als eerste weg. Zonder iemand wiens werk dit ís, veroudert het systeem sneller dan de producten die het moet bedienen.
Niemand weet voor wie het bedoeld is
Een design system voor 'alle teams' is een systeem zonder doelgroep. Een marketingsite en een klantportaal hebben andere behoeften, en als het systeem doet alsof dat niet zo is, past het voor allebei half. Dan haakt iedereen op een ander punt af.
Er is geen verwachting vastgelegd
Teams weten niet of een component stabiel is, of hij volgende maand verandert, en of er iemand reageert als hij stuk is. Bij die onzekerheid kiest een verstandig team voor eigen code, want dat is voorspelbaar. Dat is geen onwil maar risicobeheer.
Geen duidelijkheid over wat er wel en niet in hoort
Een team weet niet of zijn behoefte thuishoort in het systeem, en vraagt het daarom niet. Dan bouwt het lokaal. Elke lokale variant is een stuk UI dat permanent buiten het systeem valt.
Je kunt niet voor al je gebruikers migreren
Voor consumenten in dezelfde repo voer je een migratie zelf uit. Voor de rest lever je een versie en wacht je af. Daar wordt elke wijziging een onderhandeling, en groeit de afstand tussen wat het systeem is en wat er draait.
Adoptie wordt niet gemeten
Zonder cijfers is adoptie een gevoel, en gevoelens zijn optimistisch. Je merkt pas dat het systeem is weggezakt als iemand toevallig kijkt, en dan is de achterstand al groot. Wat je niet meet kun je ook niet verdedigen als er om budget wordt gevraagd.
Wat dat in de praktijk betekent
Een project is af, een product heeft een eigenaar, een doelgroep en een roadmap. Dat verschil bepaalt drie dingen. Je legt vast welke doelgroepen je bedient en wat elk van hen mag verwachten, bijvoorbeeld een kernset die je gegarandeerd onderhoudt, een tweede laag zonder harde belofte en experimenteel materiaal op eigen risico. Je gaat zitten bij de engineers die je componenten dagelijks gebruiken en kijkt mee terwijl ze werken. En je meet niet het aantal componenten, want dat groeit vanzelf, maar welk aandeel van de UI uit het systeem komt.
Teams hebben er meer aan te weten waar ze aan toe zijn dan dat alles even goed is.
Wat helpt
Wat niet helpt
Hoe dit er in de praktijk uitziet
Bij Rabobank werkte Simplor twee jaar aan het design system voor de front-end organisatie: drie teams op twee losse platforms, met overlappende componenten en een positionering die niemand kon uitleggen. Het zwaartepunt lag niet bij componenten bouwen maar bij opnieuw bepalen welke doelgroepen er zijn en wat je per groep belooft. Daaruit volgden product tiers en service niveaus.
Technische consolidatie liep parallel aan nieuwe functionaliteit, want een systeem dat een half jaar alleen opruimt verliest zijn gebruikers. Templates en layouts waren daarin de belangrijkste uitbreiding: een niveau boven losse componenten, waarmee een team een paginaopzet kiest in plaats van bouwt. Resultaat na twee jaar: twee teams op één geconsolideerd platform, gepositioneerd voor ongeveer tweehonderd development teams.
Wie pakt de migratiepijn
Elke deprecation, verwijdering of update maakt migratiewerk. De enige vraag is wie dat doet. Zit een consument in dezelfde monorepo als het systeem, dan voert het systeemteam de migratie zelf uit en merkt de gebruiker er weinig van. Zit hij in een andere repo, dan lever je een versie met een changelog en wacht je af. Dat gebeurt later, of niet.
Dat bepaalt wat je kunt beloven. Waar je zelf migreert, kun je toezeggen dat je meeneemt wat je breekt. Waar dat niet kan, moet je terughoudender zijn met breaking changes en langer blijven ondersteunen, want de rekening ligt bij iemand anders. Consumenten naar de monorepo halen is daarmee geen technische keuze maar een adoptiekeuze.
Schaalgrootte bepaalt de problemen niet
Tweehonderd teams of drie: dezelfde vijf vragen. Wie is eigenaar, voor wie is het bedoeld, wat mag een team verwachten, wat hoort er wel en niet in, en zit je consument in dezelfde repo of niet. Alleen het apparaat eromheen beweegt mee met je omvang. Bij drie teams is de eigenaar iemand met een halve dag per week en zijn de tiers een lijstje van tien componenten die je belooft te onderhouden.
Begin bij eigenaarschap en een nulmeting: zet één naam erop en meet welk aandeel van je UI nu uit het systeem komt. Twijfel je of je überhaupt een systeem hebt of vooral gedeelde code, begin dan bij het verschil tussen een design system en een componentenbibliotheek.