Designsystemen: één bron van waarheid

Een site groeit zelden volgens plan. Er komt een actiepagina bij, een nieuw formulier, een tweede taal. Elke keer kiest iemand een knop, een kleur en een afstand, en elke keer net iets anders. Na een paar jaar heeft je site vier soorten knoppen en drie tinten van je eigen blauw, en niemand weet meer welke de juiste is.

Een designsysteem voorkomt dat. In dit artikel lees je wat het is, hoe het verschilt van een stijlgids of merkboek, wat erin zit, wanneer een mkb-site er een nodig heeft en wanneer het te veel is, hoe je het opbouwt en bijhoudt, en wat je bij de oplevering mag verwachten.

Wat is een designsysteem?

Een designsysteem is de vaste set waaruit elk scherm van je site of app wordt gemaakt, met de regels erbij. Het bestaat uit vier lagen:

• Tokens: de kleinste ontwerpkeuzes met een naam, zoals een kleur, een lettergrootte of een afstand.
• Componenten: de onderdelen die je steeds opnieuw gebruikt, zoals een knop, een invoerveld, een kaart of een melding.
• Patronen: vaste combinaties van onderdelen voor een taak, zoals een formulier met foutmeldingen of een rij kaarten met een filter.
• Richtlijnen: wanneer je wat gebruikt, en waarom.

Het belangrijkste woord is “één”. Ontwerp en code putten uit dezelfde bron. Verandert de hoofdkleur, dan verandert hij op één plek, en elke knop, link en kop die hem gebruikt, verandert mee. Daarom heet een designsysteem ook wel één bron van waarheid.

Wat is het verschil met een stijlgids, merkboek of componentenbibliotheek?

De woorden lopen door elkaar, en dat maakt offertes lastig te vergelijken. Zo verhouden ze zich:

Een merkboek gaat over je hele merk, ook op een bus of een visitekaartje. Een designsysteem gaat over schermen. Het neemt de kleuren en letters uit het merkboek over, maar bepaalt daarnaast dingen die een merkboek niet regelt: hoe een uitgeschakelde knop eruitziet, wat er gebeurt als een veld verkeerd is ingevuld, en welke tint groen er op een witte achtergrond leesbaar genoeg is. Meer over het merkboek lees je bij branding.

Wat levert een designsysteem op?

Vier dingen, als het goed wordt bijgehouden:

• Eén gezicht. Elke pagina oogt hetzelfde, ook de pagina die over twee jaar wordt toegevoegd.
• Minder keuzes per pagina. Wie een nieuwe pagina maakt, kiest uit bestaande onderdelen in plaats van opnieuw te ontwerpen.
• Wijzigen op één plek. Een nieuwe kleur of een groter lettertype pas je één keer aan, niet op veertig pagina's.
• Dezelfde taal. Ontwerper en bouwer noemen een onderdeel bij dezelfde naam, dus er wordt minder gegokt bij de bouw.

Vaak hoor je dat een nieuwe pagina dan in uren staat in plaats van dagen. Hoeveel tijd het precies scheelt, hangt af van de site en van wie hem bijhoudt. Dat hebben wij niet gemeten, dus een getal noemen we niet.

Wat zit er in een designsysteem?

Tokens: ontwerpkeuzes met een naam

De W3C Design Tokens Community Group, een groep van ontwerpers, ontwikkelaars en makers van ontwerpprogramma's, omschrijft een token als informatie met een leesbare naam, op zijn minst een paar van naam en waarde. Op 28 oktober 2025 verscheen de eerste stabiele versie van hun specificatie (2025.10). Die legt vast hoe je tokens in een JSON-bestand opschrijft, zodat ontwerpprogramma's en code ze kunnen uitwisselen. Het formaat kent onder meer tokens voor kleur, afmeting, lettertype, letterdikte en duur.

Het nuttige zit in de lagen. De documentatie van Material Web, de webonderdelen van Googles Material Design, beschrijft drie soorten tokens: referentietokens met een vaste waarde, zoals een kleurcode, systeemtokens die een rol vastleggen, en componenttokens voor één onderdeel. Een knop gebruikt dan niet “groen #1C6A45”, maar “de kleur voor de hoofdactie”, en die rol wijst naar de kleurcode. In Material Web zijn tokens CSS-variabelen.

Bij onze klanten zie je die rollen terug op de casepagina's. Bij Ikiz draagt nachtblauw de site, en markeert zeegroen wat je moet zien, zoals labels en knoppen. Bij TaalPro is oranje de kleur van de knoppen, en heeft elk taalniveau een eigen kleur, van rood-oranje voor A1 tot amber voor C1.

Componenten: onderdelen met al hun situaties

Een knop is niet één plaatje. Hij heeft situaties: gewoon, aangeklikt, uitgeschakeld, en wat er verschijnt als iets misgaat. Een invoerveld heeft er meer: leeg, ingevuld, gekozen met het toetsenbord, fout, en goed. Een goed component heeft al die situaties uitgewerkt, zodat de bouwer niet zelf hoeft te bedenken hoe een foutmelding eruitziet. Dat is ook het verschil tussen een mooi ontwerp en een bruikbaar systeem: het ontwerp toont de gewone situatie, het systeem alle situaties.

Patronen: onderdelen samen voor een taak

Een patroon is een vaste oplossing voor iets wat steeds terugkomt: een formulier in stappen, een zoekveld met resultaten, een prijsblok, een rij vragen en antwoorden. Het legt vast welke onderdelen erin zitten en in welke volgorde. Een nieuwe dienstpagina hoeft dan niet opnieuw ontworpen te worden; hij krijgt dezelfde opbouw als de andere.

Richtlijnen: wanneer gebruik je wat?

Richtlijnen zijn de korte zinnen die verkeerd gebruik voorkomen. Eén hoofdknop per scherm. De accentkleur alleen op een donkere achtergrond. Foutmeldingen zeggen wat er mis is en hoe je het oplost. Ook de woorden in knoppen en meldingen horen hierbij; meer daarover lees je in ons artikel over microcopy.

Toegankelijkheid: in het systeem, niet erachteraan

Hier wint een designsysteem het meest. Reken je het contrast één keer goed na in de tokens, dan klopt het op elke pagina die ze gebruikt. Andersom geldt het ook: een fout in een token zit meteen overal. De eisen komen uit de WCAG, de richtlijnen van het W3C. Voor kleur zijn dit de belangrijkste op niveau AA:

Volgens het W3C mag je de uitkomst niet afronden: 4,499:1 is te weinig. Een kleur die in je logo prima werkt, is dus niet vanzelf goed genoeg voor tekst. Daarom heeft een designsysteem soms twee tinten van dezelfde merkkleur: één voor het merk en één voor tekst. Wat de wet vraagt, lees je in ons artikel over de toegankelijkheidswet.

Heeft een mkb-site een designsysteem nodig?

Een lichte versie wel, een volledig systeem lang niet altijd. Een site van vijf pagina's die je eens in de paar jaar vernieuwt, heeft genoeg aan vastgelegde kleuren, letters, afstanden en een handvol onderdelen. Een set waarin elk onderdeel al zijn situaties heeft, met uitgeschreven patronen en richtlijnen, is een project op zich. Dat is pas zinvol als er veel schermen bijkomen of als meer mensen eraan werken.

Een voorbeeld van dat laatste is NL Design System: geen gewoon designsysteem, schrijft het zelf, maar een verzameling designsystemen van onder meer gemeenten en overheidsorganisaties, die samen ontdekken welke componenten in de praktijk werken. Een huisstijl kan er als thema worden vastgelegd. Dat is het soort schaal waarvoor een volledig systeem bedoeld is. Voor de meeste mkb-sites is het een maat te groot, maar het laat goed zien hoe tokens en thema's samenwerken.

Wat verandert er bij een licht en donker thema?

Met tokens is een tweede thema geen tweede site. Elke rol krijgt per thema een eigen waarde, en de onderdelen blijven gelijk. Het werk zit in het narekenen: elke combinatie van tekst en achtergrond moet in beide thema's aan de contrasteisen voldoen. Een kleur die op wit goed leesbaar is, is dat op bijna zwart vaak niet.

Sittard Taxi heeft twee complete thema's. De site opent donker, een knop zet hem licht, en die keuze wordt onthouden. Wie 's nachts een taxi bestelt, kijkt niet in een fel wit scherm. Elk thema heeft zijn eigen kleuren; het donkere is geen omgekeerd licht. Het accent is mint (#00C896) in het lichte thema en neonmint (#7CFFB4) in het donkere. Ook Basestep, ons eigen product, heeft een donkere en een lichte modus, met een knop bovenaan elke pagina.

En bij meer talen?

Elke taal maakt teksten langer of korter, en dat moet in elk scherm passen. Een knop die in het Nederlands past, kan in het Duits over twee regels lopen. Een taal die van rechts naar links leest, draait bovendien de hele opmaak om. Bij TaalPro bestaat elke pagina drie keer, in het Nederlands, Engels en Farsi; het Farsi draait de hele opmaak om, met Vazirmatn als letter. Een systeem dat daar vanaf het begin rekening mee houdt, scheelt veel losse correcties.

Hoe bouw je een designsysteem op?

Wij beginnen bij de tokens, dan de kerncomponenten, dan de patronen die ze combineren. Bij ons ontstaat alles in Figma, van wireframe tot designsysteem met tokens en componenten. In stappen:

1. Kijk wat er al is. Bij een bestaande site verzamel je elke knop, elk veld en elke kleur die er nu op staat. Dat overzicht laat zien wat dubbel is en wat ontbreekt.
2. Leg de tokens vast. Kleuren met een rol, letters met hun groottes, afstanden in een vaste reeks. Reken het contrast na voordat het vastligt.
3. Maak de kerncomponenten. Knop, link, invoerveld, keuzevak, kaart, melding, menu. Elk met al zijn situaties, ook voor het toetsenbord.
4. Bouw de patronen. De vaste combinaties voor de taken op jouw site: aanvragen, boeken, zoeken, vergelijken.
5. Breng het over naar code. Dezelfde namen en waarden als in het ontwerp, zodat wat je ziet ook is wat er gebouwd wordt. Voor de bouw liggen afstanden, gedrag en uitzonderingen vast.
6. Schrijf het op. Per onderdeel wanneer je het gebruikt en wanneer niet. Kort, met een voorbeeld.

Begin niet met alles. De eerste versie hoeft alleen te bevatten wat je nu nodig hebt. Wat er later bijkomt, sluit aan op dezelfde tokens. Hoe dat in een volledig traject loopt, lees je bij UI/UX design; voor een gewone website bij webdesign.

Hoe houd je een designsysteem bij?

Een designsysteem dat niet wordt bijgehouden, veroudert sneller dan de site zelf. Iemand heeft haast, bouwt een knop buiten het systeem om, en een jaar later zijn er weer vier. Vijf gewoontes houden het bij elkaar:

• Eén eigenaar. Iemand beslist wat erin komt. Dat kan je bouwer zijn, of iemand in je eigen team.
• Eerst in de set kijken. Is er een nieuw onderdeel nodig, kijk dan eerst of een bestaand onderdeel het kan. Zo niet, voeg het toe aan het systeem in plaats van aan één pagina.
• Wijzigen in het token, niet op de pagina. Een kleur die op één pagina met de hand is aangepast, raakt bij de volgende wijziging zoek.
• Opruimen met aankondiging. Een onderdeel dat weg moet, markeer je eerst als verouderd. De specificatie van het W3C heeft daar zelfs een eigen veld voor.
• Contrast opnieuw narekenen. Na elke kleurwijziging, in elk thema.

Kleine dingen pas je zelf aan: een tekst, een beeld. Wie er later een scherm bij maakt, pakt uit de vaste set. Grotere ingrepen in de opbouw lopen via ons, of via een onderhoudsabonnement als je dat liever uit handen geeft.

Wat krijg je bij de oplevering?

Vraag het elk bureau, ook ons. Dit is wat bij ons standaard meekomt:

• Een stijlgids: kleuren, typografie en componenten, vastgelegd. Hij hoort bij de drie documenten die je bij elke oplevering krijgt, naast een beheerhandleiding en technische notities.
• De ontwerpbestanden in Figma, met volledige toegang. Bij betaling komen ze op jouw naam, net als domein, code en data.
• Een overdracht naar de bouw met afstanden, gedrag en uitzonderingen. Dat geldt voor onze bouw, maar ook als een andere partij bouwt.
• Bij een huisstijltraject je kleuren en letters ook als code, zodat een bouwer ze direct gebruikt.

Alleen onze algemene bouwstenen blijven van ons. Hoe de zes fasen van een project lopen, lees je in onze werkwijze. Bij een kleine site van een paar pagina's is een lichte versie genoeg, en dat zeggen we dan ook.

Wanneer dit niet geldt

Heb je een site van een handvol pagina's die zelden verandert, dan is een volledig designsysteem vooral extra werk. Vastgelegde kleuren en letters en een paar vaste onderdelen zijn dan genoeg. Werk je met een gekocht thema in een bestaand systeem, dan bepaalt dat thema al veel; een eigen designsysteem ernaast kan dan dubbel werk opleveren.

Wat we niet weten: we hebben niet gemeten hoeveel tijd een designsysteem bij onze klanten scheelt. Contrast is maar één deel van toegankelijkheid; automatische tests vinden lang niet alle problemen, en ook ArtsenPool noemt zichzelf nog gedeeltelijk voldoend. Het formaat van de Design Tokens Community Group is in oktober 2025 stabiel geworden; welke programma's het al volledig lezen, hebben wij niet nagelopen.

Veelgestelde vragen

Benieuwd hoeveel systeem jouw site nodig heeft? Vertel ons hoe groot hij is en wie hem bijhoudt, dan zeggen we of een lichte versie genoeg is. Wat het kost, staat bij prijzen. Je werkt rechtstreeks met Nawid; per project zet hij een vast team van specialisten in.

Bronnen

Geraadpleegd op 3 november 2026.

• W3C, Design Tokens Community Group (eerste stabiele versie op 28 oktober 2025)
• Design Tokens Community Group, Design Tokens Format Module 2025.10 (28 oktober 2025)
• W3C, Understanding WCAG 2.2: 1.4.3 Contrast (Minimum)
• W3C, Understanding WCAG 2.2: 1.4.11 Non-text Contrast
• W3C, Understanding WCAG 2.2: 2.4.7 Focus Visible
• Material Web (Google) op GitHub, Theming: design tokens
• NL Design System
• Empireyo, case ArtsenPool
• Empireyo, case Sittard Taxi
• Empireyo, case TaalPro
• Empireyo, case Ikiz
• Empireyo, case Basestep
• Empireyo, Werkwijze (stijlgids, beheerhandleiding en technische notities)
• Empireyo, UI/UX design (situaties per onderdeel, Figma, lichte versie)
• Empireyo, Webdesign (designsysteem met tokens en componenten in Figma)
• Empireyo, Logo en huisstijl (kleuren en letters als code)