UX-case study
Een design system leeft alleen als het als code wordt gebruikt
Dit is een terugkerend project, één poging bij elk bedrijf waar ik sinds 2017 heb gewerkt. Eén verschil bepaalde welke ervan nog in gebruik was toen ik wegging: of de library in het product was gecompileerd of was opgeslagen als document om te raadplegen. De methode veranderde over al die pogingen nauwelijks, totdat agentic AI zijn intrede deed en de methode licht verschoof. Wat volgt is hoe de laatste ervan is gebouwd, en wat de eerdere mij hebben geleerd door tekort te schieten.
Probleem
Niemand besluit om vier verschillende knoppen te bouwen
Design is in een bedrijf van elke omvang gedecentraliseerd, en dat is met goede reden: een designer werkt bij één team, leert het probleem van dat team kennen en levert op volgens de roadmap van dat team. De kosten komen later, en ergens anders. Zet de schermen van twee van die teams naast elkaar en de verschillen zijn direct zichtbaar.
Dit speelt op elke schaal. Aan de kleine kant is het een letterstijl die net niet klopt, of een grijstint die bestaat omdat iemand hem uit een screenshot heeft overgenomen. Aan de grote kant is het een hele flow die niet had moeten bestaan, gebouwd omdat het team dat hem nodig had niet kon weten dat een ander team het al had opgelost.
Wat dit lastig te repareren maakt, is dat het geen kwaliteitsprobleem is. Elk van die schermen is zorgvuldig gemaakt door iemand die zijn vak verstaat. De inconsistentie is een bijwerking van de structuur, dus de oplossing moet ook structureel zijn, en een document dat designers vraagt consistent te zijn is geen structuur. Het is een verzoek.
Het te bouwen ding is dus geen stijlgids. Het is een plek waar designers en de front-end developers die geneigd zijn zich druk te maken om user experience samen een taal kunnen vastleggen, en een route waarlangs wat zij afspreken onderdeel wordt van de productarchitectuur.
Doelen
Wat een system moet doen om de sprint waard te zijn
Team & publiek
Eén sprint van de vier, en geen product owner
De opzet die voor mij het beste heeft gewerkt, is een geleend team in plaats van een vast team. Één designer en één front-end developer van elk productteam, die volgens een vast schema samenkomen.
Drie sprints van gewone productoplevering zijn hoe het team ontdekt wat de library daadwerkelijk mist, zodat de vierde aankomt met een wachtrij waar iemand de behoefte al aan heeft gevoeld, in plaats van een lijst met verbeteringen die in een kamer zijn verzonnen.
Het waren zes mensen: vier front-end developers vanuit elk team, en twee designers. We werkten met een kanbanbord en hadden geen product owner.
Zonder die persoon kwam het schrijven van tickets op mij neer. Het meeste ervan was klein en specifiek. Af en toe was dat niet zo: bijvoorbeeld elk kleur- en typografietoken naar W3C-contrastrichtlijnen brengen.
Publiek
Wie het daadwerkelijk opent
De begunstigde is de klant. De gebruikers zijn vier groepen binnen een bedrijf.
Scope en beperkingen
Wat geen experiment nodig had
Bijna niets van dit werk werd getest, en dat was de juiste keuze. Twee belangrijke beslissingen maakten het grootste deel ervan uit, en geen van beide is het soort vraag dat een experiment kan beantwoorden.
Het eerste is het verwijderen van een variatie die niemand heeft gekozen. Als een product drie grijstinten heeft waarvan twee teams er elk één hebben verzonnen en niemand kan zeggen waar de derde voor dient, dan is ze samenvoegen geen hypothese. Er is geen uitkomst denkbaar die pleit voor het behouden van een ongelukje.
Het tweede is het toepassen van richtlijnen die al bestaan en beter onderbouwd zijn dan alles wat wij zelf zouden kunnen uitvoeren. Contrastverhoudingen zijn het duidelijkste geval: W3C heeft het werk al gedaan, op een steekproefgrootte die geen enkel bedrijf zelf bereikt, en dit lokaal opnieuw testen om te zien of onze gebruikers ook liever dingen kunnen lezen, zou theater zijn.
Wanneer een verandering echt een vraag was, verliet die dit team. Die ging naar het productteam dat die flow bezat, waar een product owner was om het te prioriteren en een data scientist om de test te ontwerpen.
Proces
Zes stappen, en de eerste drie zijn politiek
De volgorde is belangrijk. Drie van deze zes gebeuren voordat er ook maar één component is gemaakt, en ze overslaan is hoe een design systeem een map wordt die iemand ooit heeft gemaakt.
In kaart brengen wat er al is
Een inventarisatie vóór een voorstel. Kleuren, tekstvelden, lettertypefamilies, toggles, sliders, popups, knoppen, splitknoppen, galerijen, en elke variatie daarvan die het product bleek te bevatten.
Het op te leveren product is de visuele versie van de lijst, want een aantal van dertien knopstijlen is een getal waarover iemand kan discussiëren, en dertien knoppen naast elkaar op drie slides niet. Dit is het artefact dat de volgende stap mogelijk maakt, en het is de tijd die het kost waard.
De catalogus bleek zijn eigen beste bewijsstuk te zijn, wat ik pas ontdekte bij het herbouwen van deze pagina ervandaan. Bij Findhotel staat de primaire knop er drie keer in, in drie verschillende blauwtinten: #3979F5 op de knoppenslide, #0074F8 in de header, #4476FB in de dialogen. Niemand had bewust voor drie gekozen.
Formulier
13Knoppen
13Weergave
9Containers
8Afbeeldingen
Menu's
Navigatie
Overlays
- #3979F5Knoppenslide, Search
- #0074F8Headersectie, Search
- #4476FBDialog, Back to form
Één primaire knop, drie blauwtinten. Dit is de inventarisatie die haar eigen zaak bepleit.
De tijd vrijkopen
Met de inventarisatie in de hand zetten een lead developer en ik een presentatie neer voor de mensen die tekenen voor waar sprints naartoe gaan. Het publiek koos zichzelf. De mensen die al klaagden dat het product er op verschillende plekken niet als zichzelf uitziet, waren degenen die dit écht zouden maken, want zij hadden het probleem al opgemerkt en hadden er geen naam voor.
Dat is de hele truc van deze stap. Niemand financiert een design systeem als abstractie. Ze financieren het zodra ze de dertien knoppen hebben gezien, en op dat moment gaat het argument niet meer over of consistentie in principe goed is.
De presentatie stelt de vraag wat de problemen zijn en beantwoordt die met de simpele antwoorden: features komen traag uit, niemand weet zeker welke componenten al bestaan of hoe ze te gebruiken, kleine bugs in componenten worden nooit opgelost, toegankelijkheid ontbreekt door de hele applicatie. Op zichzelf gelezen is het de zaak die bij elk bedrijf gemaakt zou kunnen worden.
Het team samenstellen uit alle teams
Één designer en één developer uit elk productteam.
Een team dat overal vandaan komt, heeft een vertegenwoordiger in elke ruimte waar de library later gebruikt gaat worden. Dat is wat adoptie verandert van een uitrol in iets dat al is gebeurd, en het is het verschil tussen een library die het bedrijf gebruikt en een library die alleen de auteurs gebruiken.
Vier productteams, en de zes mensen die hun sterke punten bundelen: vier front-end developers en twee UX-designers.
Tools kiezen
Op het gebied van design kwam het neer op twee keuzes: waarin ontworpen werd, en waar het gepubliceerd werd. Bij Maersk was InVision in 2019 al gelicentieerd en veelgebruikt. Bij Findhotel was dat Zeplin. Beide bedrijven gebruikten Sketch. In elk geval was het antwoord de tool die al in gebruik was.
Op het gebied van development was er een nieuwe eis, in plaats van een overgeërfde: de belangrijkste overweging was om het publiceren en debuggen van een component zo automatisch mogelijk te maken.
De tijden zijn sindsdien veranderd; Figma wordt breed gebruikt als de voorkeurstool voor UX-designers. Storybook heeft nog altijd zijn plek in de ontwikkelcyclus. Wat werkelijk veranderde, zit onder de tools. Een designer die met agentic AI zoals Claude Code werkt, kan de component direct schrijven en committen, in plaats van te vertrouwen op een developer om de wijzigingen door te voeren.
Componenten maken, en afspreken wat een component is
Verdeeld onder de designers, één component per keer, en de eenheid van werk is het component in al zijn staten.
Twee designers die dat werk verdelen, produceren twee onverenigbare helften, tenzij iemand opschrijft wat 'klaar' betekent, dus dat deed ik. Negen voorwaarden werden opgeschreven als een vorm van acceptatiecriteria voor het design systeem.
- Flexibel bij resizing met autolayout
- Gebruikmakend van de officiële lijst met benoemde tekststijlen
- Gebruikmakend van de officiële lijst met benoemde kleuren
- Precies passend binnen het eenhedenraster, waarvan de kleinste eenheid 4px is
- Met een mobiele, tablet- en desktopversie, waar dat van toepassing is
- Geeft zo min mogelijk bewerkrechten vrij en blijft toch bruikbaar
- Correct benoemd, inclusief elke sublaag
- Getest op een canvas op schalen en op rechten
- Gepubliceerd op het officiële platform
Drie ervan kun je beter zien dan lezen, want elk is een regel over een vorm.
Vormregels
Publiceren, waar de discussie wordt beslecht
Dit is de stap die mijn eerdere pogingen fout deden, en die fout ziet er op dat moment niet uit als mislukking. Met InVision publiceerde ik naar designers. Designers gebruikten het. De resultaten waren prima en de producten dreven toch uit elkaar, want een designsilo en een ontwikkelsilo leveren dezelfde drift op als helemaal geen system, één overdracht later.
Design wordt uiteindelijk code of het gaat niet live. Dus mijn werk richtte zich meteen op de developers. Componenten werden één op één gekoppeld tussen de designkant en de ontwikkelkant, elk met een unieke URL die was geïndexeerd in een bestand dat de front-end kon lezen.
Hieronder staat één component, de sterrenbeoordeling, op de drie plekken waar hij bestaat. Het is hetzelfde object, met variaties.
Wat er is opgeleverd
Pagina's die uit het design system kwamen
Deze pagina's zijn volledig samengesteld uit onderdelen die zijn gemaakt in de bijbehorende design systemen.
Floorplanner, 2018
Een tekentool in plaats van een funnel. De twee marketingpagina's aan het eind zijn de interessante, want een marketingpagina die is samengesteld uit de componenten van het product zelf is een voorbeeld waarin de gids verder reikte dan het kernproduct.
Maersk, 2019
Twill, Maersk's platform for the small and medium exporters and importers who book LCL (less than container load) cargo: shipments too small to fill a container, sharing the space and the cost with other people's freight. The screens below follow one booking from the destination search to the confirmation screen.
Findhotel, 2020
De hele funnel, op desktop, tablet en mobiel. De mobiele opnamen zijn volledige pagina-exports.
Zimmer Biomet, 2021
Een chirurgische planner, in achttien maanden gebouwd. De meeste vensters in dit product zijn één component met andere inhoud erin. Verander de component één keer en elk venster verandert mee.
TrackBee, 2025
Vijf stromen getoond op drie breedtes elk: inloggen, een account aanmaken, advertentieplatforms koppelen, een abonnement kiezen, en terugkomen na een verlopen abonnement.
Conclusie
Een levend designsysteem is een systeem dat gecodeerd is
Toen ik vertrok was het een levende library, geïmporteerd door elk product in de portfolio in plaats van eraan gerefereerd.
Elke component naar de toegankelijkheidsrichtlijnen van W3C brengen veranderde alle producten tegelijk, en dat is een duidelijk voorbeeld van succes.
Bij Coolblue in 2017 en bij Maersk in 2019 was wat ik bouwde gericht op designers, met beperkte betrokkenheid van developers, en beide waren overgeleverd aan wie er toevallig in een bepaald team zat: het was de taak van die designer om naar de componenten te grijpen, ze actueel te houden en ze goed toe te passen. Dat is te veel om aan de nauwgezetheid van één persoon op te hangen, en het is geen kritiek op wie dan ook van de betrokken designers. Een systeem waarvan het handhavingsmechanisme is dat iemand eraan denkt, is een systeem dat bij de eerste drukke sprint achteruitgaat.