Eén bibliotheek voor design en code
Zonder vaste componenten begint elk ontwerp min of meer opnieuw: flows opbouwen duurt lang, aanpassingen doorvoeren duurt nóg langer en er sluipen overal kleine verschillen in. Samen met een tweede designer en het front-end team bouwde ik een componentenbibliotheek die zowel in Figma als in code bestaat, met dezelfde componenten, dezelfde eigenschappen bewaard in tokens.
- Rol
- UX/UI-designer, componenten opzetten en toepassen
- Team
- 2 designers + front-end team
- Tools
- Figma, Material Design als basis
- Tijdlijn
- Doorlopend, naast andere projecten
Het probleem
Er waren inconsistenties door de hele interface heen: dezelfde knop zag er op twee plekken net anders uit, een inputveld had drie varianten. Daardoor duurde het opbouwen van designs en flows onnodig lang, en kostte snel iets aanpassen of een prototype bouwen telkens meer tijd dan nodig.
Wat er nodig was, was één set vaste bouwstenen voor design en development samen: knoppen, tabellen, inputvelden met dropdowns en datepickers, notificaties, navigatiebalken, tooltips, chips, file inputs, iconen, kleuren, typografie, en custom componenten zoals een history log.
Aanpak
Ik maakte de componenten en gebruikte ze meteen zelf in mijn designs en flows. Dat was ook de beste test. Pas als je een component echt in een flow gebruikt, merk je of hij klopt.
De componenten zetten we samen met het front-end developerteam op. Zo ontstond niet alleen een bibliotheek in Figma, maar ook een pagina in de browser met de daadwerkelijk gebouwde HTML/CSS-componenten ernaast.
Een 8- en 4-punts grid
Alle maten en afstanden volgen een 8-punts grid, met stappen van 4 voor de fijnere details. Dat maakt spacing een keuze die je één keer maakt in plaats van bij elk scherm opnieuw.
Tokens, kleur & typografie
Kleuren, spacing en typografie liggen vast als tokens. Eén bron voor design en code, zodat een wijziging niet op tien plekken handmatig hoeft.


De componenten
Van knoppen en inputvelden tot tabellen, datepickers en custom componenten zoals de history log, elk met zijn varianten en statussen.








Belangrijke keuzes
Niet alles hoeft een component te zijn
Als een component telkens losgekoppeld en anders gebruikt moet worden, kost hij meer tijd dan hij oplevert. Een modal bijvoorbeeld: die verschilt per situatie zo sterk dat een vaste component alleen maar in de weg zou zitten.
Kleuren niet automatisch laten genereren
Automatisch berekende tints geven niet altijd het beste resultaat. We stelden de tinten zelf vast, zodat elke kleur er in de praktijk ook echt goed uitziet.
Werken met tokens
Door kleuren, spacing en typografie als tokens vast te leggen blijft alles consistent. Eén aanpassing in de bron werkt overal tegelijk door, in design én in code.
Material Design als basis
Niet alles vanaf nul bouwen. Material Design gebruikten we al, het is groot en populair (dus veel documentatie en voorbeelden van goed opgebouwde componenten) en het komt met mooie, stabiele iconen die gratis te gebruiken zijn in development.
Een 8- en 4-punts grid
Alle spacing en maten volgen een 8-punts grid, met 4 punten voor de fijnere details. Daardoor sluiten componenten vanzelf op elkaar aan en hoeft er over afstanden niet telkens opnieuw nagedacht te worden.
Challenges
De grootste uitdaging was steeds de afweging: waar houdt een component op nuttig te zijn? Sommige elementen werden zo vaak losgekoppeld en aangepast dat ze als component meer werk kostten dan ze bespaarden. Een modal was daar het duidelijkste voorbeeld van.
Resultaten
- Een volledig bruikbare designbibliotheek in Figma.
- Een pagina in de browser met de gebouwde HTML/CSS-componenten ernaast.
- Betere samenwerking met de front-end developers: componenten zijn duidelijk benoemd en samen opgezet, dus over de overdracht hoeft niet meer onderhandeld te worden.
- Een sneller en makkelijker ideation-proces, omdat de basis en de meeste onderdelen al klaarliggen.
- Consistentie door tokens: één wijziging in de bron werkt overal door.
Reflectie
Een volgende keer zou ik nog eerder samen met het front-end team testen. Hoe eerder een component in echte code staat, hoe sneller je merkt of hij in de praktijk klopt.
Ook is het belangrijk om wijzigingen aan de bibliotheek niet te lang op te sparen. In kleine batches updaten betekent dat je, als er iets breekt, meteen weet waar het vandaan komt.