Het fundament onder alle nieuwe LogicTrade-modules — gestart als ondersteuning bij het bouwen van de eerste next-gen schermen, uitgegroeid tot een levend systeem met drie werkende prototypes.
Ontstaan uit noodzaak, niet uit een briefing
Het design system is niet als apart project gestart, maar ontstond terwijl ik de eerste next-gen modules bouwde. Om Offerte snel en consistent te kunnen ontwerpen, had ik herbruikbare bouwstenen nodig — kleuren, type, componenten, gedragspatronen. Wat begon als praktische ondersteuning groeide uit tot een volwaardig systeem, met mij als maker, bewaker en eindverantwoordelijke.
Twee drijfveren, één urgentie
Zonder gedeeld systeem zou elke nieuwe module — Offerte, Service, Planning, en de 10+ die daarna volgen — zijn eigen kleurkeuzes, button-stijlen en loading-gedrag ontwikkelen. Dat drift binnen een paar modules al uit elkaar.
Die noodzaak werd urgenter toen het hele productteam overstapte op een agentic werkwijze: developers werken nu met Claude en Codex, in hoog tempo. Die manier van werken is vanuit de organisatie opgelegd — developers zijn geen designers, en bij die snelheid ligt inconsistentie voortdurend op de loer. Een klassiek design system, gericht op mensen die het rustig doorlezen, volstond niet meer.
Alle bouwstenen, plus het bewijs dat ze werken
Niet alleen tokens en regels op papier, maar een systeem dat zich bewijst in echt werkende software én bruikbaar is voor de agents die nu meebouwen. Naast de designprincipes (merk, kleur, typografie, loading- en empty states) bouwde ik drie werkzame prototypes — Offerte, Service, Planning — die het systeem direct toetsten aan een echte flow, in plaats van aan een geïsoleerde stijlgids.
Geen klassiek design system
Het resultaat bestaat uit drie lagen, elk met een eigen doelgroep — mens, machine, of beide.
Werkende schermen waarop ik als designer kan zien en voelen of het systeem in de praktijk klopt — de menselijke check.
Herbruikbare bouwstenen die zowel in Figma als in code direct toepasbaar zijn, voor designer én developer.
Rules en guidelines, geschreven in markdown, speciaal gestructureerd zodat Claude en Codex ze kunnen lezen en volgen.
Van Claude Code naar Lovable
De prototypes zijn gebouwd met Claude Code. Op verzoek van mijn leidinggevende is het geheel verplaatst naar Lovable, zodat het systeem makkelijk bereikbaar is voor development en andere belanghebbenden binnen de organisatie — geen lokale setup nodig, gewoon een link.
De obstakels onderweg
Developers itereren nu razendsnel met Claude en Codex. Regels die achterlopen op de praktijk zijn binnen dagen al achterhaald — de MD-structuur moest dus net zo snel bij te werken zijn als het development-team zelf werkt.
Met een groeiend systeem kun je niet alles tegelijk formaliseren. Prioriteren op wat development écht nodig had, in plaats van een compleet maar te laat systeem nastreven.
Elke volgende module (Service, Planning, en verder) bracht eigen edge cases mee, die het systeem moest kunnen absorberen zonder inconsistent te worden.
Wat het systeem stuurt
"Elke kleur, elk component heeft een betekenis — niet decoratie, maar gedrag."
Dat principe is letterlijk vastgelegd: merkblauw is gereserveerd voor interactie, magenta uitsluitend voor status, groen alleen voor bevestigende acties. Hetzelfde geldt voor gedrag — skeletons boven spinners, een vaste 400ms-vertraging voordat een skeleton verschijnt, minimaal 500ms zichtbaar om flikkeren te voorkomen. Geen esthetiek, maar regels die zowel een designer als een agent zonder twijfel kan toepassen.
Merkblauw = interactie, magenta = status, groen = bevestiging. Nooit decoratief.
Timing, states en transities zijn exacte regels, geen richtlijn bij benadering.
Elke afspraak moet even ondubbelzinnig zijn voor een designer als voor een AI-agent.
Een greep uit het systeem
Het fundament onder alles wat nog komt
Het systeem groeide mee met wat de organisatie er daadwerkelijk van nodig had — van stijlgids naar bouwbare, agent-leesbare basis onder alles wat LogicTrade nu en straks bouwt.
Wat ik hiervan meeneem
Toen development meer bleek nodig te hebben dan visuele richtlijnen, had ik het project strak binnen de oorspronkelijke scope kunnen houden. In plaats daarvan liet ik het systeem meegroeien naar een hybride met een component library — omdat de vraag kwam uit echte gebruiksbehoefte, niet uit scope creep zonder reden.
Met de agentic werkwijze van development moest het systeem ook leesbaar worden voor Claude en Codex, niet alleen voor mensen. Dat veranderde wat "goede documentatie" betekent — structuur en consistentie werden nog belangrijker dan alleen visuele duidelijkheid.