Het Design System opzetten voor SERA

Introductie

Tijdens mijn stage bij Sera Business Design werkte ik aan het opzetten van een design system voor alle drie de hoofd producten van Sera: DataDuiker, DataWijzer, en ERP. Het doel was om consistentie binnen de designs te verbeteren.

De context

Voordat ik aan dit project begon, kende de software veel inconsistenties in de interface. Deze problemen hadden meerdere oorzaken.

Ten eerste speelde UX lange tijd een beperkte rol binnen het bedrijf. De focus op UX is pas in de afgelopen jaren gegroeid, waardoor grote delen van de bestaande software nooit zijn geüpdatet of opnieuw ontworpen volgens actuele UX-standaarden.


Daarnaast had er een half jaar voor de start van mijn stage een overstap plaatsgevonden van Adobe XD naar Figma. Door deze toolwissel ontbrak een centrale plek waar ontwerpkeuzes, componenten en stijlafspraken waren vastgelegd en gedeeld.


Het ontbreken van een design system zorgde ervoor dat pagina’s onderling sterk van elkaar verschilden. Hoewel er wel enkele richtlijnen bestonden die programmeurs gebruikten tijdens het ontwikkelen, waren deze niet vastgelegd of afgedwongen. Wanneer een situatie afweek van de bestaande regels, werden oplossingen ad hoc bedacht en geïmplementeerd, wat de inconsistentie verder vergrootte.

Het doel

Het doel van het design system is om alle ontwerpen binnen de software consistenter te maken. Het biedt houvast bij het maken van nieuwe designs en zorgt ervoor dat iedereen op dezelfde manier werkt. Of er nu een nieuw scherm wordt ontworpen of een nieuwe designer bij Sera begint, het design system helpt om alles logisch op elkaar aan te laten sluiten.


De scope van dit project is groot en bewust open gelaten. Er zit geen vaste deadline op, omdat een design system nooit echt af is. Het verandert en groeit mee met de software en met het team. Nieuwe inzichten, nieuwe features of nieuwe wensen zorgen er steeds voor dat het design system verder wordt aangescherpt en uitgebreid.

Onderzoek & Analyse

Voor het opzetten van het design system heb ik onderzocht welke aanpak het beste past bij de uitdagingen binnen de bestaande software. Hierbij heb ik gekeken naar twee veelgenoemde structuren binnen design systems: foundations en Atomic Design, om te begrijpen welke het meest geschikt is voor dit project.


Binnen een design system worden foundations gezien als de visuele basislaag die zorgt voor consistentie in de interface. Foundations bestaan uit stijlregels zoals kleur, typografie, spacing, grid, en design tokens, die het fundament vormen voor een consistente UI-ervaring (Atlassian, Foundations). Deze basisregels helpen om visuele herkenbaarheid en samenhang te creëren door het hele product heen. Foundations zijn belangrijk omdat ze de bouwstenen zijn die designers gebruiken bij het maken van componenten en layouts (Atlassian, Foundations; OnlineDepartment).


Atomic Design daarentegen is een methodiek die verder gaat dan enkel visuele regels. Het biedt een hiërarchische structuur waarin interfaces worden opgebouwd uit herbruikbare onderdelen, van de kleinste elementen (atoms) tot complete pagina’s (templates en pages) (Frost, Atomic Design; UXcel). In deze aanpak zijn de foundations onderdeel van de kleinste bouwstenen (zoals kleur en typografie als tokens binnen atoms), maar de focus ligt vooral op hoe componenten zich tot elkaar verhouden, hergebruikt worden en samen een schaalbare interface vormen.


Het grootste verschil tussen deze twee benaderingen is dat foundations vooral dienen als een visuele basislaag, maar niet vanzelf structuur bieden voor componentgedrag of hergebruik binnen grotere systemen. Atomic Design helpt juist om consistentie en schaalbaarheid te waarborgen door componenten op een doordachte manier te structureren en te combineren (UXpin; UXcel). Aangezien de grootste uitdaging binnen de software niet alleen visuele inconsistentie was, maar juist ongestructureerd componentgebruik en gebrek aan hergebruik, sluit Atomic Design beter aan bij deze probleemstelling.


Op basis van deze inzichten heb ik gekozen om Atomic Design te gebruiken als de overkoepelende aanpak voor het design system, waarbij foundations onderdeel zijn van de atoms en tokens binnen het systeem, en niet de primaire structuur. Deze keuze zorgt ervoor dat het systeem niet alleen visueel consistent is, maar ook logisch gestructureerd, schaalbaar en praktisch toepasbaar voor zowel designers als developers.

Onderzoek & Analyse

Op basis van het onderzoek is ervoor gekozen om Atomic Design te gebruiken als hoofdaanpak voor het design system. Deze methode sluit het beste aan bij de uitdaging binnen de software, namelijk het gebrek aan structuur en herbruikbaarheid in componenten. Door te werken met een duidelijke hiërarchie van kleine naar grotere bouwstenen, wordt consistentie niet alleen visueel bewaakt, maar ook in opbouw en gedrag van componenten.


Hoewel foundations een belangrijk onderdeel blijven van het design system, zijn deze niet als los startpunt gebruikt. In plaats daarvan zijn visuele basisafspraken zoals kleur, typografie en spacing verwerkt binnen de kleinste bouwstenen van het systeem. Hierdoor vormen foundations de basis van de atoms, in plaats van een aparte laag zonder directe koppeling aan componenten.


Daarnaast is er bewust gekozen om het design system af te stemmen op de bestaande technische werkwijze. In overleg met de developers is besloten om Bootstrap als uitgangspunt te blijven gebruiken. Deze keuze zorgt ervoor dat het design system niet losstaat van de code, maar direct aansluit op bestaande componentstructuren en naming. Hierdoor wordt het systeem niet alleen bruikbaar voor designers, maar ook praktisch toepasbaar voor developers.


Tijdens het ontwerpen stonden een aantal principes centraal:

  • consistentie boven individuele oplossingen

  • herbruikbaarheid van componenten

  • schaalbaarheid voor toekomstige uitbreiding

  • nauwe aansluiting tussen design en development


Deze ontwerpstrategie zorgde ervoor dat het design system niet werd opgezet als een statisch document, maar als een flexibel en groeiend systeem dat meebeweegt met de software en het team.

Opzet van het Design System

Na het bepalen van de ontwerpstrategie is het Design System concreet opgezet binnen Figma. De focus lag hierbij op overzicht, herbruikbaarheid en schaalbaarheid, zodat het systeem niet alleen prettig werkt voor designers, maar ook goed aansluit op de dagelijkse praktijk van development.


Het Design System is opgebouwd volgens de principes van Atomic Design. De kleinste bouwstenen vormen de basis voor grotere componenten, waarbij visuele basisafspraken zoals kleur, typografie en spacing direct zijn verwerkt in deze componenten. Hierdoor wordt consistentie automatisch afgedwongen in zowel uiterlijk als gedrag.


Om te voorkomen dat componenten verkeerd of in de verkeerde context worden gebruikt, is het Design System bewust opgesplitst in drie afzonderlijke libraries (zie Figuur 1, opsplitsing van het Design System en de components):

  • Design System
    Bevat alle gedeelde tokens en basiscomponenten die zowel in de frontoffice als in de backoffice worden gebruikt. Deze library vormt de kern van het systeem en wordt altijd toegevoegd aan een Figma-bestand.

  • Backoffice Components
    Bevat componenten die exclusief bedoeld zijn voor de backoffice, zoals beheerschermen, complexe formulieren en tabellen.

  • Frontoffice Components
    Bevat componenten die uitsluitend worden gebruikt in de frontoffice, zoals klantgerichte schermen en interacties.


Deze opsplitsing is bewust gemaakt om te voorkomen dat frontoffice-componenten per ongeluk in de backoffice worden gebruikt, of andersom. Door de libraries te scheiden, wordt het voor designers direct duidelijk welke componenten beschikbaar en bedoeld zijn voor de context waarin zij werken.

In de praktijk betekent dit dat bij het starten van een ontwerp altijd eerst de Design System library wordt toegevoegd aan het document voor toegang tot alle tokens en gedeelde componenten. Vervolgens wordt, afhankelijk van het type scherm, óf de Backoffice Components library óf de Frontoffice Components library toegevoegd (zie Figuur 2, Voorbeeld hoe in een backoffice project de library's toegevoegd zijn). Op deze manier blijft het ontwerp overzichtelijk en wordt verkeerd gebruik van componenten actief voorkomen.


Binnen Figma is deze structuur verder ondersteund door duidelijke naming, consistente hiërarchie en het gebruik van componentvarianten. Hierdoor kunnen designers snel de juiste componenten vinden en toepassen, terwijl de scheiding tussen frontoffice en backoffice behouden blijft.


Deze opzet zorgt ervoor dat het Design System niet alleen consistent is, maar ook veilig en schaalbaar in gebruik. Het systeem ondersteunt groei van de software, zonder dat de complexiteit voor designers of developers onnodig toeneemt.

Figuur 1, opsplitsing van het Design System en de components

Figuur 2, Voorbeeld hoe in een backoffice project de library's toegevoegd zijn

Implemenatie

Het Design System is niet opgezet als een project met iteraties, maar als een levend systeem dat continu wordt bijgewerkt. Wanneer er nieuwe inzichten ontstaan of wanneer componenten aangepast moeten worden, worden deze wijzigingen direct doorgevoerd in het Design System. Hierdoor blijven er geen verouderde versies bestaan en werken we altijd met de meest actuele componenten.

In plaats van te werken met afzonderlijke iteraties of historische versies, is ervoor gekozen om het Design System steeds direct aan te passen wanneer dit nodig is. Dit voorkomt dat er meerdere varianten van componenten naast elkaar blijven bestaan en zorgt ervoor dat consistentie behouden blijft binnen de software.

Deze werkwijze vraagt om duidelijke afspraken binnen het team. Ontwerpkeuzes worden afgestemd met developers en gecontroleerd op technische haalbaarheid voordat zij worden doorgevoerd. Door deze nauwe samenwerking blijft het Design System realistisch en direct toepasbaar binnen de bestaande codebase.

De opsplitsing tussen het centrale Design System en de frontoffice- en backoffice libraries speelt hierin een belangrijke rol. Doordat gedeelde componenten op één centrale plek worden beheerd, kunnen wijzigingen gecontroleerd en bewust worden doorgevoerd, zonder ongewenste gevolgen voor specifieke contexten.

Deze aanpak zorgt ervoor dat het Design System actueel, overzichtelijk en betrouwbaar blijft.

Resultaten en Impact

Het succes van het Design System zit niet in een opvallend uitblinkmoment, maar juist in hoe vanzelfsprekend het systeem aanvoelt in gebruik. Bij het ontwerpen van nieuwe schermen is het eenvoudig om de juiste componenten te pakken en samen te stellen, zonder dat er maatwerk of extra ontwerpkeuzes nodig zijn.

Een goed voorbeeld hiervan is te zien in

Figuur 1, Screenshot van een backoffice scherm met gelabelde componenten. Dit backoffice-scherm is volledig opgebouwd uit bestaande componenten uit het Design System en de backoffice component library. Vrijwel alle onderdelen van het scherm zijn herbruikbare bouwstenen, waardoor het ontwerp consistent blijft met de rest van de applicatie.


In dit scherm zijn de volgende Design System componenten toegepast:

  1. Breadcrumb
    Laat zien waar je je bevindt binnen de applicatie.

  2. Button
    Word gebruikt om een actie mee uit te voeren

  3. Input field
    Standaard invoerveld voor het invullen of zoeken van informatie.

  4. Progress indicator
    Geeft een snel overzicht van een status

  5. Pagination
    Hiermee kan de gebruiker door meerdere pagina’s met resultaten bladeren.

  6. Table footer
    Toont de standaard components aan die in een table footer moeten zitten.


  7. Sidebar navigation
    De vaste navigatie aan de linkerkant van de backoffice.

  8. Select component
    Select om een keuze te maken, bijvoorbeeld bij filters.

  9. Checkbox
    Wordt gebruikt om één of meerdere items te selecteren.


Alle componenten maken gebruik van dezelfde tokens voor kleur, typografie en spacing. Doordat deze componenten centraal zijn vastgelegd in het Design System, kunnen schermen als deze snel worden opgebouwd en blijven ze consistent binnen de gehele applicatie.

Het Design System dwingt geen opvallende keuzes af, maar zorgt ervoor dat consistente keuzes vanzelf worden gemaakt. Juist deze vanzelfsprekendheid laat zien dat het Design System werkt zoals bedoeld.

Reflectie

Het werken aan het Design System heeft mij vooral geleerd hoe belangrijk structuur en duidelijke afspraken zijn binnen een product dat blijft groeien. In plaats van steeds per scherm of feature keuzes te maken, dwingt een Design System je om op een hoger niveau na te denken: wat is gedeeld, wat is context-specifiek en hoe zorgen we dat dit ook op lange termijn blijft werken?


Een belangrijk inzicht was dat een goed Design System niet opvallend hoeft te zijn. Juist het feit dat het vanzelfsprekend aanvoelt om een component te pakken en te gebruiken, laat zien dat het systeem werkt. Tijdens het ontwerpen merkte ik dat ik minder tijd kwijt was aan visuele keuzes en meer focus kon leggen op flow en inhoud, omdat de basis al vastlag.


De opsplitsing tussen het centrale Design System en de frontoffice- en backoffice component libraries was een keuze die in de praktijk goed uitpakte. Het voorkomt verwarring, maakt het systeem overzichtelijk en helpt om fouten te voorkomen. Tegelijkertijd vraagt deze aanpak om discipline: wijzigingen moeten bewust worden doorgevoerd en afgestemd met developers, zodat het systeem consistent blijft.


Doordat het Design System continu wordt bijgewerkt en niet werkt met vaste iteraties, heb ik geleerd om ontwerpbeslissingen zorgvuldiger te maken. Een aanpassing heeft direct impact op meerdere plekken, wat het belang van overleg en afstemming vergroot. Deze manier van werken heeft mijn begrip van samenwerken met development en het onderhouden van een schaalbaar systeem versterkt.


Als ik dit project opnieuw zou doen, zou ik mogelijk eerder documenteren waarom bepaalde keuzes zijn gemaakt, zodat deze kennis makkelijker overdraagbaar blijft voor nieuwe teamleden. Tegelijkertijd ben ik tevreden over hoe het Design System nu functioneert als een stabiele basis voor verdere ontwikkeling.


Dit project heeft mij laten zien dat een Design System niet alleen een ontwerptool is, maar vooral een hulpmiddel voor samenwerking, consistentie en groei.

Bronnen

Atlassian. (z.d.). Foundations.
https://atlassian.design/foundations


Frost, B. (2016). Atomic design (Chapter 2). https://atomicdesign.bradfrost.com/chapter-2/


OnlineDepartment. (z.d.). Design System implementatie. https://www.onlinedepartment.nl/ux-design/design-system/

UXcel. (2025). What is a design system, and how to build one. https://uxcel.com/blog/what-is-a-design-system-and-how-to-build-one/

UXpin. (2024). Top 3 Design System Structures. https://www.uxpin.com/studio/blog/design-system-structure/