11 dec 2025·6 min
Consistente UI in React-apps met design tokens en regels
Leer prompten voor consistente UI in React-apps met design tokens en componentregels, zodat AI-gegeneerde schermen overeenkomen qua spacing, typografie en formulieren.
Leer prompten voor consistente UI in React-apps met design tokens en componentregels, zodat AI-gegeneerde schermen overeenkomen qua spacing, typografie en formulieren.
UI-inconsistentie valt meestal op in kleine details die niet kloppen als je rondklikt. De ene pagina heeft royale padding, de andere voelt krap aan. Koppen springen tussen groottes, knoppen veranderen van vorm en kleur, en hetzelfde invoerveld gedraagt zich anders per scherm.
Meestal komt de drift voort uit een paar basiszaken:
Dit komt vaak voor wanneer schermen worden gegenereerd uit losse prompts. Elke prompt is feitelijk een frisse start, dus het model vult missende beslissingen door te raden. Zelfs “gebruik moderne styling” laat honderden kleine keuzes over: 8px versus 12px gaps, 14px versus 16px bodytekst, wanneer fouten getoond worden, hoe een primaire knop eruitziet.
Je kunt twee of drie pagina's handmatig bijwerken, maar dat schaalt niet. Je jaagt one-off CSS-fixes na, kopieert stijlen tussen bestanden en maakt formulieren opnieuw in orde. De regels zitten in je hoofd, niet in het project.
Stel je voor dat je vandaag een login-scherm genereert en morgen een profielscherm. Als het ene scherm fouten pas bij submit toont en het andere op blur, merken gebruikers het. Als de hoogte van de primaire knop wisselt tussen schermen, voelt de app geplakt aan.
Consistentie wordt de standaard wanneer elk scherm volgens hetzelfde gedeelde systeem werkt: design tokens (spacing, type, kleur) plus een kleine set component- en formulierregels.
Design tokens zijn simpele benoemde waarden die je hergebruikt in de UI. In plaats van bij elk scherm te vragen om “comfortabele padding”, gebruik je een token zoals space-4. In plaats van “licht afgerond” gebruik je radius-md. De naam blijft hetzelfde, zelfs als je later verandert waar deze naar verwijst.
Tokens zijn de set beslissingen die je wilt dat elk scherm deelt. Ze halen smaak en gokken weg, en dat is precies wat drift veroorzaakt bij generatie of nieuwe pagina's bouwen.
Typische tokens dekken spacing, typografie, kleuren, vorm en een kleine set elevations. Het voordeel is praktisch: een header gebruikt altijd dezelfde grootte, een card altijd dezelfde padding, en een primaire knop behoudt kleur en radius.
Tokenizeer de dingen die het algehele gevoel door het product beïnvloeden: spacing-scale, fontgroottes en lijnhoogtes, kernkleuren (tekst, achtergrond, primary, danger, border) en een kleine set border-radii.
Laat contentgedreven keuzes flexibel, zoals copy-lengte, welke icoon te gebruiken of of een sectie twee of drie cards nodig heeft.
Als je schermen genereert (ook met tools zoals Koder.ai), vermindert een kleine tokenset vooraf de hoeveelheid gokken en maakt de output merkbaar consistenter.
Een tokenset is gewoon een kort menu van toegestane waarden. Klein is beter omdat het minder ruimte voor willekeurige keuzes laat, maar het moet wel de basics dekken die schermen fout laten voelen.
Begin met spacing. Kies één schaal en gebruik die overal voor padding, gaps en layout. Een set zoals 4, 8, 12, 16, 24, 32 dekt de meeste UI. Als een ontwerp 10px of 18px vraagt, rond dan af naar de dichtstbijzijnde token in plaats van nieuwe getallen in te voeren.
Definieer daarna typografie-standaarden zodat koppen en bodytekst niet meer gaan afwijken. Je hebt geen enorm typesysteem nodig, wel duidelijke, herhaalbare stappen.
Een compacte set die bruikbaar blijft zonder te opgeblazen te raken:
Toegankelijkheid hoort ook in het systeem. Definieer een focus-outline-stijl (kleur, dikte, offset) zodat toetsenbordgebruikers consistente focusstaten krijgen. Stel een minimum tap-target in (zoals 44x44) voor mobiel. Beperk tekstkleuren tot een kleine, vertrouwde set om contrast voorspelbaar te houden.
Als knoppen soms krap ogen, komt dat vaak doordat het ene scherm padding 10 gebruikte en het andere 12. Met tokens kun je zeggen: “Knoppen gebruiken paddingY=8, paddingX=16, radius=12, focus-outline-token, min height 44.” Als die getallen vastliggen stopt de generator met improviseren.
Tokens zetten de getallen. Componentregels zetten de gewoonten.
Kies een kleine set kerncomponenten en behandel ze als de enige bouwstenen voor schermen. Houd ze saai en herbruikbaar: Button, Input, Select, Checkbox, Card. Je kunt TextArea en Modal toevoegen, maar die moeten hetzelfde systeem volgen (labels, spacing, staten).
Beperk vervolgens varianten en definieer wanneer ze zijn toegestaan. Bijvoorbeeld: Button heeft primary, secondary en danger. Primary is voor de belangrijkste actie op het scherm (meestal één). Secondary is voor annuleren of lage-prioriteit acties. Danger alleen voor destructieve acties zoals verwijderen. Als de variant niet te rechtvaardigen is, default naar secondary.
Spacingregels voorkomen subtiele drift. Definieer defaults binnen componenten: Button-padding, Input-hoogte, label-tot-veld gap, de standaard gap tussen gestapelde velden. Voeg ook enkele lay-outregels toe: Cards hebben vaste interne padding en consistente header/body spacing; Modals gebruiken dezelfde width-steps en footer-alignment.
Maak tenslotte staten niet-onderhandelbaar, want hier beginnen UIs vaak willekeurig te lijken:
Als je een formulier-zwaar scherm genereert zoals “Create project”, voorkomen deze regels gemixte knopgroottes, verschuivende labelposities of een one-off “special” card die op slechts één pagina verschijnt.
Zelfs met stabiele visuals komen veel “het voelt niet goed”-klachten van formuliergedrag. Als elk scherm labels, fouten en focus anders behandelt, ervaren gebruikers inconsistentie.
Kies één formulierpatroon en gebruik het overal: label, optioneel/verplicht-markering, hulptekst, daarna fouttekst. Houd de woordkeuze ook consistent (bijv. labels in sentence case, korte hulptekst en foutmeldingen die met een werkwoord beginnen).
Regels die de meeste drift voorkomen:
Vergrendel maatvoering en layout zodat schermen niet verschillend “ademen”. Definieer één inputhoogte, één knophoogte en een standaard veldbreedte. Op desktop lijn velden uit op een consistent grid en stap labels boven inputs. Op mobiel maak velden full width en vermijd tweekolomsformulieren tenzij echt nodig.
Een simpel voorbeeld: een “Create project”-scherm kan Name, Region en Description hebben. Zelfs als Region een select is, behandel het als elk ander veld: dezelfde hoogte, dezelfde labelpositie, dezelfde foutregel. Als de gebruiker met een lege Name submit, verplaatst de focus naar Name, verschijnt de fout eronder en blijft de layout stabiel.
Als je schermen in Koder.ai genereert, zet deze formulierregels één keer in je prompt en hergebruik ze over features zodat elk nieuw formulier hetzelfde gedraagt zonder herhaalde schoonmaak.
Behandel je prompt als een klein UI-contract. Houd het kort, specifiek en herbruikbaar zodat elk nieuw scherm zich aan dezelfde spacing, typografie, componenten en gedragingen houdt.
Een praktisch patroon is om een compacte UI-spec bovenaan je verzoek te plakken en daarna het scherm in gewone taal te beschrijven.
UI SPEC (apply to every screen)
Tokens:
- Spacing: 4, 8, 12, 16, 24, 32
- Radius: 8
- Typography: H1 24/32, H2 18/26, Body 14/20
- Colors: text, muted, bg, primary, danger (no custom hex)
Components (must use): PageShell, Section, Card, Button, Input, Select, TextArea, FormRow, HelperText, Toast
Layout rules:
- Page padding: 24 desktop, 16 mobile
- Section spacing: 24
- Card padding: 16
- Grid: 12 cols desktop, 4 cols mobile, gap 16
Do:
- Reuse components and tokens only
- Keep labels above inputs, helper text below
Do not:
- Invent new spacing values, font sizes, or one-off CSS
- Mix different button heights or input styles
If a new component is needed:
- Extend an existing component pattern and document it in the output
- Do not create new visual styles outside tokens
Na de spec voeg je een paar acceptatiechecks toe die drift vroeg vangen:
Als je een chat-gebaseerde generator gebruikt, houd deze spec stabiel tussen verzoeken. Het elke keer veranderen leidt het doel voorbij.
Schrijf het UI-contract voordat je iets genereert: een kleine tokenset (spacing, type, kleuren, radius, schaduwen) plus een korte componentinventaris (Button, Input, Select, Card, Modal, Table, Toast). Als een token of component ontbreekt, zal het model er een uitvinden en zal je UI gaan driften.
Maak daarna één referentiescherm dat de regels oefent. Een formulier-zware pagina is een goede stresstest omdat die headers, hulptekst, validatiefouten, primaire en secundaire knoppen en een succes-toast bevat. Behandel dat scherm als baseline.
Bouw nieuwe schermen door te componeren met wat je al hebt gedefinieerd. Vraag niet om “verse styling.” Vraag om dezelfde Card, dezelfde spacing-scale, dezelfde typografie-stappen en hetzelfde veldpatroon.
Een eenvoudige workflow:
Als een "Search users"-scherm uiteindelijk strakker gespaced is dan de referentie, tweak dan niet handmatig marges. Update de spacing-tokens of Card-paddingregel één keer en genereer opnieuw.
Als je in Koder.ai werkt, helpen snapshots en rollback: vergrendel een baseline, experimenteer veilig en rol snel terug als een wijziging drift introduceert.
De snelste manier om consistentie te verliezen is tokens en regels als suggesties behandelen. Kleine uitzonderingen vermenigvuldigen zich over nieuwe schermen.
Een veelvoorkomende valkuil is de spacing-scale halverwege het project veranderen. Vroege schermen gebruiken 8, 16, 24. Een nieuw scherm introduceert 10 en 18 “omdat het er beter uitziet.” Nu is drift toegestaan en oude schermen worden nooit bijgewerkt.
Een andere driftbron is de generator nieuwe componentstijlen laten uitvinden. Als je niet zegt “alleen deze knopvarianten bestaan,” kan het een nieuwe radius of andere input-padding op één scherm creëren.
Staten zijn ook een frequente miss. Loading-, empty- en error-staten veranderen vaak spacing en gedrag. Als je ze er achteraan plakt, krijg je meestal gehaaste patronen die niet bij de rest passen.
Let ook op het verkeerde soort specificiteit: “maak het modern met zachte schaduwen” is vaag, terwijl gedragsregels als “fouten tonen onder het veld”, “disabled knoppen behouden focus-stijlen” en “Enter submit alleen op laatste veld” concreet en herhaalbaar zijn.
Als je een lichtgewicht guardrail-blok wilt om in prompts te plakken, houd het kort:
Voer een tweeminuten-scan uit voordat je een gegenereerd scherm merged.
Begin met spacing. Zoek naar willekeurige waarden zoals 13px of one-off margins die “er gewoon in gezet zijn”. Als je tokens gebruikt, moet elke gap uit de goedgekeurde set komen, inclusief gutters, card-padding en spacing tussen formuliervelden.
Controleer vervolgens typografie aan de hand van je type-scale. Koppen moeten voorspelbaar aflopen. Bodytekst mag niet van grootte wisselen tussen vergelijkbare secties. Lijnhoogte doet er ook toe, zeker op dichte schermen zoals instellingenpagina's.
Scan knoppen. Varianten en groottes moeten je regels volgen: primary voor hoofdhandeling, secondary voor minder belangrijke acties, danger alleen als het echt verwijdert. Knophoogte, icoonplaatsing en labelstijl moeten overeenkomen.
Voor formulieren gaat consistentie vooral over structuur. Labels blijven op één plek, verplicht-indicatoren volgen één regel, hulptekst en fouten concurreren niet en fouten verschijnen op een consistente plek.
Een korte checklist:
Doe tenslotte een korte mobile check. Verklein de breedte en bevestig dat de layout meebeweegt zonder nieuwe fontgroottes of spacing te verzinnen.
Stel je een eenvoudige onboardingflow voor: drie schermen (Profile, Preferences, Confirm), plus later een Settings-pagina. Je wilt dat elk scherm voelt alsof het van dezelfde ontwerper komt, zelfs als ze in aparte runs zijn gegenereerd.
Voordat je iets genereert, geef je een kleine tokenset en een paar componentregels op:
TOKENS
- spacing: xs=4, sm=8, md=12, lg=16, xl=24
- radius: sm=8, md=12
- type: body=14/20, title=20/28, label=12/16
- layout: pageMax=960, sectionGap=24, fieldGap=12
COMPONENT RULES
- Page: max width=pageMax, padding=xl, sectionGap between blocks
- Card: padding=lg, radius=md
- Field: label above, helper below, fieldGap between fields
- Button row: primary on right, gap=sm
- Errors: shown under field, same copy style, no alerts
Genereer nu “Profile” en “Preferences” afzonderlijk. Omdat beide schermen Page, Card, Field en Button row moeten gebruiken zoals gedefinieerd, krijgen ze dezelfde marges, label-spacing en knopplaatsing. De Confirm-stap past nog steeds, ook al heeft die meer read-only tekst.
Formuliergedrag is waar drift vaak sluipt, dus definieer het één keer en hergebruik het: submit uitgeschakeld totdat geldig, inline fouten alleen na blur of submit, Enter submit alleen op de laatste stap, en de Back-knop wist nooit eerder ingevulde waarden.
Als je een nieuw UI-onderdeel nodig hebt, laat het model het niet improviseren. Voeg één regel toe en genereer opnieuw met hergebruik in gedachten:
Zet tokens en regels om in een herbruikbare spec die je daadwerkelijk gebruikt. Als het te lang is om te plakken, wordt het niet gevolgd.
Een praktische spec bevat meestal: je token-tabel (spacing, type, radii, kleuren), een korte componentregelsset (buttons, inputs, cards, koppen), formuliergedragsregels (validatietiming, fouten, disabled/loading), lay-out-standaarden (page-padding, max width, sectie-afstand) en een korte “nooit doen” lijst (willekeurige margins, ad-hoc fontgroottes).
Maak er vervolgens één gewoonte van: update de spec eerst, niet individuele pixels.
Als je Koder.ai gebruikt, is planning mode een goede plek om de spec te herhalen en bevestigen voordat je UI genereert. Als je alternatieven wilt proberen, helpen snapshots en rollback je te experimenteren zonder een stabiele basis te verliezen.
Omdat elk schermverzoek een nieuw begin is. Als je geen gedeeld systeem meegeeft, vult de generator de ontbrekende details door te raden—spacing, lettergroottes, knop-padding, schaduwen en formuliergedrag—waardoor kleine verschillen zich over pagina's ophopen.
Design tokens zijn genoemde, herbruikbare waarden voor zaken als spacing, lettergroottes, kleuren en radius.
In plaats van “comfortabele padding” gebruik je iets als space-md. De naam blijft stabiel en elk scherm hergebruikt dezelfde beslissing, waardoor de UI minder snel afwijkt.
Begin klein en dek alleen wat zichtbare drift veroorzaakt:
Zet een compacte UI-spec-blok bovenaan elk verzoek en behandel het als een contract:
Beschrijf daarna het scherm. Het belangrijkste is dat de spec onveranderd blijft tussen schermen.
Tokens definiëren de getallen; componentregels definiëren de gewoonten. Nuttige regels zijn onder andere:
Standaardregel: als een variant niet te rechtvaardigen is, val terug op de standaardvariant.
Kies één patroon en breek het nooit:
Dit voorkomt het veelvoorkomende probleem dat het ene scherm valideert op blur en een ander alleen op submit, wat gebruikers opvalt.
Definieer een paar niet-onderhandelbare statusregels:
Als je staten niet specificeert, verzint elk scherm vaak zijn eigen patronen.
Voeg het als een gedocumenteerde uitbreiding toe van een bestaand patroon:
Als je het niet met tokens kunt beschrijven, is het meestal te aangepast en zal het drift veroorzaken.
Maak één referentiescherm dat het systeem test (een formulier-zware pagina werkt goed) en hergebruik dezelfde spec voor elk nieuw scherm.
In Koder.ai kun je planning mode gebruiken om de spec te herhalen en bevestigen voordat je genereert; gebruik snapshots en rollback om een stabiele basislijn te bewaren tijdens experimenten.
Gebruik een korte scan voordat je het scherm accepteert:
Als iets niet klopt, update de spec/tokens en genereer opnieuw—patch geen one-off margins.
Als je een “nieuwe” waarde nodig hebt, rond af naar de dichtstbijzijnde token in plaats van 10px of 18px te introduceren.