Dienst · Software-ontwikkeling

Design system laten maken voor meerdere product-teams.

Eén bron van waarheid voor uw kleuren, typografie, componenten en interactie-patronen. Beschikbaar in Figma én als code-library, gedocumenteerd in Storybook, en gemaakt om door meerdere teams tegelijk gebruikt te worden zonder dat het uit elkaar valt.

Design tokensComponent libraryStorybookMulti-brand themes

Plan een kennismaking Bekijk ons werk

Een design system is geen UI-kit met een mooie naam.

Een UI-kit is een verzameling Figma-componenten. Mooi om naar te kijken, maar zodra meerdere product-teams ermee gaan werken loopt het uit elkaar: kleuren wijken af, spacing klopt niet meer, buttons worden steeds opnieuw uitgevonden, accessibility zakt weg per team en niemand weet welke versie waar in productie staat. Het Figma-bestand wordt steeds slechter gesynchroniseerd met de werkelijkheid op het scherm.

Een echt design system koppelt design en code aan elkaar via tokens, levert een geversioneerde component-library, documenteert keuzes in Storybook, en heeft governance om te voorkomen dat het systeem na een paar releases stilstaat. Dat bouwen wij voor scale-ups met meerdere product-teams, enterprises met een multi-product portfolio en organisaties die een design system willen uitrollen over meerdere web-applicaties.

De grootste belofte is niet visuele consistentie — dat is een prettig bijproduct. De echte belofte is snelheid: een team dat een nieuwe pagina maakt grijpt naar bestaande, gevalideerde componenten en levert in dagen wat zonder system in weken zou gaan. Accessibility wordt eenmalig goed gedaan en daarna overal geërfd. Een rebrand wordt een token-wijziging, geen project per applicatie.

Drie rollen waarin wij instappen.

Niet elk traject start op nul. Soms bestaat er al een Figma-library, soms is er alleen een merk-rebrand, soms moet een bestaand system schaalbaar worden voor meerdere merken. We passen onze rol aan op waar u staat.

Greenfield · van scratch opgebouwd

Nieuw design system bouwen

U bent ergens halverwege opschaling, hebt twee of drie product-teams die ieder hun eigen UI uitvinden, en wilt nu één systeem dat overal werkt. We zetten samen met uw design-team (of ons design-partner) de fundering op: tokens, basis-componenten, Storybook, en een eerste release voor pilot-teams.

Design tokensComponent libraryStorybooknpm-package

Migratie · van CSS-frameworks naar tokens

Bestaand system vernieuwen

U heeft een legacy stylesheet, een Bootstrap-vork uit eerdere jaren, of een Figma-library die de werkelijkheid in productie niet meer dekt. We migreren stap voor stap naar een tokens-based system, behouden backwards-compatibility waar nodig, en leveren codemods waarmee uw teams oude componenten kunnen swappen naar nieuwe.

Style DictionaryTokens StudioCodemodsDeprecation-paden

Multi-tenant · white-label themes

Theming voor meerdere merken

U levert een platform aan klanten die het in eigen huisstijl willen aanbieden, of u heeft een merk-portfolio met meerdere labels op dezelfde codebase. We maken het design system theme-baar: tokens zijn overschrijfbaar per tenant, componenten passen zich aan, en uw klanten kunnen via een config hun eigen kleur, typografie en logo doorvoeren. Past goed bij een multi-tenant platform.

Theme tokensBrand-overridesRuntime themingTenant-config

Wat zit er in een design system.

Het concrete leverwerk — geen marketing-laag, maar de bouwstenen waarmee uw teams iedere dag werken. Hieronder de standaard-onderdelen die wij bouwen of meebouwen, afhankelijk van waar u staat. Niet elk traject heeft alles in dezelfde diepte nodig: een organisatie met één product-team heeft minder governance nodig dan een enterprise met vijftien teams en drie merken.

Design tokensKleur, typografie, spacing, shadow, radius, motion-curves — opgeslagen als JSON/YAML en gepubliceerd als CSS-variables, JS-objects en Figma-variables via Style Dictionary of Tokens Studio.
Component libraryHerbruikbare UI-componenten: button, input, modal, dropdown, navigation, data-table, form-controls, toast, tabs. In Figma als instances en in code als framework-componenten.
Code-implementatieReact, Vue, Angular of Web Components — afhankelijk van uw stack. Gepubliceerd als npm-package (publiek of via een private registry) met semver-versies.
Storybook-documentatieElke component met do/don't, props-table, accessibility-notes, usage-patterns en code-snippets. Tegelijk de speeltuin waarin designers en developers experimenteren.
Accessibility ingebakkenWCAG AA als basis, AAA waar het kan. Keyboard-navigatie, screen-reader-labels, zichtbare focus-states, voldoende contrast — getest met axe en Playwright, niet pas achteraf aangevlogen.
Theming-laagTokens overschrijfbaar per merk, tenant of mode (light/dark/high-contrast). De component-code blijft hetzelfde, alleen de tokens veranderen.
Versionering & migration-guidesSemver, een gepland deprecation-pad voor componenten die uitfaseren, en geschreven migration-notes bij elke major release zodat product-teams weten wat ze moeten aanpassen.
Adoptie-toolingESLint-regels die afwijkingen flaggen, een dashboard dat laat zien welk team welke versie draait, en visual-regression tests via Chromatic die voorkomen dat componenten ongezien verschuiven.
Governance-modelEen werkbaar contribution-model (wie mag bijdragen, wie reviewt, hoe wordt een RFC ingediend) zodat het systeem leeft in plaats van bevroren raakt na de eerste release.

Wanneer een design system gaat lonen.

Niet elke organisatie heeft er één nodig. Onder een bepaalde schaal is een eenvoudige UI-library voldoende. Hieronder de patronen waarin een serieus design system zichzelf snel terugverdient.

Schaal

Meerdere product-teams

U heeft twee of meer product-teams die ieder aan eigen schermen werken. Zonder gemeenschappelijk fundament gaan ze inconsistent worden — andere buttons, andere modals, andere form-states. Een design system maakt onderling kopiëren legitiem in plaats van een bron van bugs.

Multi-product

Portfolio met meerdere apps

U levert meerdere applicaties die voor de klant onder hetzelfde merk vallen. Een gebruiker die switcht tussen uw apps moet niet hoeven hertrainen op een andere navigatie of andere form-conventies.

Rebrand

Merkverandering plus opschaling

U bent in een rebrand-traject of een M&A-integratie waarin twee merken samenkomen. Een tokens-based system maakt dat de visuele merkverandering één keer hoeft te gebeuren, in plaats van per applicatie.

White-label

SaaS met klant-themes

U levert software die klanten in eigen huisstijl willen aanbieden aan hun eigen gebruikers. Theming-laag is dan geen optie maar een primair feature. Zie ook multi-tenant platform en enterprise-software-trajecten.

Hoe zo'n traject loopt.

Inventarisatie & nul-meting

We brengen in kaart wat er al is: bestaande Figma-files, productie-screenshots, CSS-archeologie, conventies per team. Daarop volgt een audit met de pijnpunten die het systeem moet oplossen — vaak: inconsistente buttons, niet-toegankelijke form-states, kleur-chaos, geen single source of truth.

Token-architectuur & basis-componenten

We definiëren de tokens-laag (kleur, type, spacing, motion) en de eerste laag componenten: button, input, label, link, card, modal. Deze gaan direct in Figma én in code zodat designers en developers parallel kunnen werken. De token-architectuur kiezen we bewust: drie lagen (primitive — semantic — component) zodat een rebrand later een kwestie is van semantic-laag aanpassen, niet alle componenten hertekenen.

Storybook & eerste release

Documentatie wordt vanaf het begin meegeschreven. Niet als post-launch corvee, maar als living spec — zonder Storybook-page geen merge. De eerste npm-release is een 0.x voor de pilot-teams.

Pilot met één team

Eén product-team gaat in productie met v0.x. Bewust klein houden: het team levert feedback, we iteren, en pas dan rollen we uit. Dit voorkomt dat we een mooi systeem leveren dat in de praktijk niet past op echte schermen.

Adoptie-roll-out

Bredere uitrol naar de andere teams. Begeleiding via wekelijkse office hours, een Slack-channel waar teams direct vragen kunnen stellen, codemods voor migration en linters die afwijkingen flaggen (afwijkende kleur-waardes, hardcoded spacing, gebruik van legacy-componenten). We monitoren welk team welke versie draait — adoptie is meetbaar, geen aanname. Een dashboard laat live zien hoe ver de roll-out is en waar drift opduikt.

Governance & doorontwikkeling

Het systeem leeft. Nieuwe componenten worden bijgedragen via een RFC-proces, breaking changes via semver-major, en we monitoren visual-regressies bij elke release. Optioneel blijven wij betrokken als beheerder of we dragen het volledig over aan uw interne team.

Veelgestelde vragen.

Wat opdrachtgevers meestal willen weten voordat we starten met een design-system-traject.

Wat is het verschil tussen een UI-kit en een design system?

Een UI-kit is een Figma-bestand met componenten. Mooi om naar te kijken, maar het is alleen design — er staat geen code naast en geen documentatie onder. Een design system is design én code, gekoppeld via tokens, gedocumenteerd in Storybook, versioneerd via npm en bestuurd via een governance-model. Het verschil is praktisch: een UI-kit toont hoe iets eruit zou kunnen zien, een design system zorgt dat het in productie ook zo werkt — en blijft werken als drie teams er tegelijk aan trekken.

Wij hebben een eigen design-team — werken jullie daarmee samen?

Ja, meestal. In greenfield-trajecten zit ons engineering-team naast uw design-team. Wij vertalen Figma naar tokens en code, uw team blijft eindbaas over de visuele richting en de merk-keuzes. In trajecten waar u nog geen design-capaciteit heeft, brengen we een vaste design-partner mee — we ontwerpen niet zelf eindeloze marketing-stijlen, maar zorgen dat het ontwerp resulteert in een werkend code-systeem. De rolverdeling spreken we vooraf duidelijk af: wie tekent welk component, wie reviewt accessibility, wie heeft het laatste woord over een token-keuze.

Kunnen jullie alleen de code-library bouwen, als wij het design al hebben?

Dat is een veelvoorkomend startpunt. U heeft Figma-componenten, maar nog geen geversioneerde code-library. Wij implementeren dan de componenten in uw framework (React, Vue, Angular of Web Components), publiceren ze als npm-package, zetten Storybook op en bouwen de adoptie-tooling. Het ontwerp is van u, de bruikbare code-implementatie van ons.

Hoe regelen jullie accessibility?

Accessibility wordt vanaf het begin meegenomen, niet pas in een laatste check-sprint. Concreet: WCAG AA als basis-eis (AAA voor publieke sector waar gevraagd), keyboard-navigatie en focus-states op elk interactief component, screen-reader-labels via ARIA, voldoende kleurcontrast in elk token, en geautomatiseerde axe-tests in Storybook. Bij contractuele eisen leveren we een per-component WCAG-conformiteitsrapport zodat u kunt aantonen aan klanten of toezichthouders dat de basis op orde is. Voor zorg- en overheidsopdrachten waar accessibility een harde eis is, sluiten we het toetspakket mee aan op de European Accessibility Act en NEN-norm-eisen.

Werkt dit ook voor multi-tenant of white-label?

Ja, dat is zelfs een veelvoorkomende use-case. We bouwen een theming-laag waarin tokens overschrijfbaar zijn per tenant of merk: kleur, typografie, logo en spacing kunnen via een config-bestand of runtime-API per klant gezet worden. De component-code blijft hetzelfde, alleen de tokens veranderen. Past goed bij een multi-tenant platform of een SaaS-portfolio dat onder verschillende merken aan klanten wordt aangeboden.

Wat bepaalt de kosten van een design-system-traject?

De grootste variabelen zijn: scope van de component-library (10 basis-componenten versus 60 met data-table en form-builder), het aantal frameworks dat ondersteund moet worden (alleen React, of ook Vue en Web Components), de mate van theming (één merk of multi-tenant), en de hoeveelheid migratie-werk in bestaande applicaties. We werken met vaste sprintbudgetten zodat u per sprint kunt sturen op waar de tijd heen gaat.

Hoe lang duurt het voor het systeem bruikbaar is?

Een eerste bruikbare release (tokens plus 8-12 basis-componenten plus Storybook) staat na een paar sprints en is dan al inzetbaar in een pilot-team. Het volledige systeem met alle componenten, theming en adoptie-tooling is een traject van meerdere sprints — meestal werken we dat parallel uit naast de pilot, zodat het systeem stap voor stap groeit met de praktijk-input.

Wat als ons system na een jaar weer stilstaat?

Dat is het meest voorkomende probleem met design systems: na de initiële release verliest niemand de tijd om bijdragen te reviewen en faseert het systeem langzaam uit. Componenten worden lokaal "even gecopypaste en aangepast", drift stapelt zich op en het centrale system raakt achter de praktijk aan. We bouwen daarom altijd een governance-model in: een duidelijk contribution-pad, RFC's voor grotere wijzigingen, een review-board met design- én engineering-vertegenwoordiging, en metrics op adoptie zodat u ziet welk team op welke versie zit. Optioneel blijven wij betrokken als beheerder, of we leiden uw interne team op om het over te nemen — dan past het goed naast een bredere platform-doorontwikkeling.

Welke tools en frameworks gebruiken jullie?

Vendor-neutraal: Figma voor design (Sketch alleen bij legacy), Style Dictionary of Tokens Studio voor de tokens-pipeline, Storybook voor documentatie, React met Radix-primitives of Headless UI als framework-keuze het toestaat, Vue 3 of Web Components als de stack daarom vraagt. Voor distributie npm of een private registry (GitHub Packages, JFrog), voor visual regression Chromatic en voor interaction tests Playwright. We kiezen op basis van uw stack, niet op basis van een vaste favoriet.

Praat met ons over uw design system.

Een vrijblijvende kennismaking van een half uur. We luisteren naar waar u staat — bestaande Figma-library, rebrand-traject, multi-product portfolio of nul-situatie — en geven een eerlijk beeld van wat een passend traject inhoudt. We bespreken wat realistisch is voor uw schaal, welke onderdelen u zelf in huis heeft en waar wij invullen, en welke risico's er typisch zijn in een design-system-traject. Past dit logisch naast een headless CMS-traject of een groter platform-vernieuwing, dan benoemen we dat ook.

Plan een kennismaking Of bekijk ons werk