De AI-designsystemworkflow die eindelijk goede resultaten oplevert

De AI-designsystemworkflow die eindelijk goede resultaten oplevert

Ik heb het grootste deel van een zaterdag besteed aan een discussie met Claude over een knop.

Niet over de logica. De knop. De primaire call-to-action op een paywall-scherm voor een finance-app die ik aan het prototypen was. Ik had de Figma MCP aangesloten, Claude toegang gegeven tot mijn design system, getypt "bouw een paywall met onze componenten" — en wat eruit kwam, leek op elk ander AI-gegenereerd scherm dat ik ooit heb gezien. Afgeronde hoeken die willekeurig aanvoelden. Een verloop dat nergens in mijn systeem voorkwam. Spatiëring die bijna goed was, zoals een coverband bijna het origineel is. Dicht genoeg om te herkennen. Ver genoeg om pijn te doen.

Ik sloot het bestand. Maakte koffie. Ging zitten en las daadwerkelijk wat ik aan het doen was.

Dit is wat ik me realiseerde: ik had Claude behandeld als een toverstaf. Even zwaaien over een Figma-bestand en perfecte pixels verwachten. En ondertussen deed het model precies wat elk model doet als je het een hoop ongemarkeerde data geeft — middelen. Mijn tokens middelen met elk ander design system dat het ooit heeft gezien. Mijn knoppen middelen met elke knop op het internet. Het resultaat was een schim van mijn design system in een overtuigend kostuum.

De oplossing was geen betere prompt. De oplossing was gestructureerde trainingsdata — tokens met beschrijvingen, componenten gegroepeerd met gebruiksregels, specifieke voorbeeldschermen — en dan lokaal itereren in Claude Code voordat ik ook maar één frame naar Figma stuurde. Toen ik dat deed, ging mijn eerste versie van de UI van "ja, dit moet ik helemaal opnieuw bouwen" naar "eigenlijk hoef ik alleen twee tekststijlen aan te passen".

Dat is de workflow die ik met je wil doorlopen. Niets revolutionairs. Gewoon saaie, geduldige structuur die ervoor zorgt dat Claude zich gedraagt als een junior designer die je systeem echt heeft gelezen — niet als een dronken toerist die van design heeft gehoord.

Waarom Vanilla Figma AI en "Just Prompt It"-workflows Instorten

Laat me de faalmodus precies beschrijven, want de meeste artikelen slaan dit deel over.

Je installeert de Figma MCP-server. Je koppelt Claude aan je Figma-bestand. Je schrijft "genereer een instellingen-scherm met ons design system." Claude gaat aan de slag, leest wat metadata, produceert iets. Je opent het. Het is op manieren fout die lastig te benoemen zijn — de hiërarchie voelt niet goed, de padding is de verkeerde 16 (de 16 die in elk systeem bestaat, niet de 16 die jij gebruikt), de card shadow lijkt erop maar is net niet jouw schaduw. Technisch gezien gebruikt het je componenten. Het begrijpt alleen niet wanneer ze te gebruiken.

Dit gebeurt om een reden die meteen duidelijk is zodra je hem benoemt: een design system-bestand is geen trainingsdata. Een design system-bestand is een magazijn. Tokens zitten in de ene collectie. Componenten in een andere. Gebruiksregels staan in een Notion-document dat niemand leest. De lijm — de daadwerkelijke kennis van "wanneer gebruiken we het elevated surface versus het raised one" — bestaat alleen in het hoofd van je senior designer.

Wanneer Claude dat magazijn leest, ziet het namen en waarden. Het ziet geen intentie. En zonder intentie wordt elke ambigue beslissing opgelost door statistisch middelen met alles wat het ooit op internet heeft gezien. Zo krijg je dus een paywall die vaag op Stripe lijkt, vaag op Linear, en totaal niet op jouw app.

Figma’s eigen standpunt hierover is eigenlijk vrij duidelijk — ze hebben een gids gepubliceerd voor het bouwen van custom skills precies om deze reden. De MCP-server wordt geleverd met basis-skills zoals figma-use en figma-generate-library, maar dat zijn slechts steigers. Ze verwachten dat je je eigen domeinkennis erbovenop legt. De meeste mensen doen dat niet. Vervolgens geven ze het model de schuld.

Ik gaf het model ook de schuld. Tot ik ermee stopte.

Er is nog een derde probleem dat de meeste tutorials ontwijken, en daar komen we later op terug in het implementatiegedeelte — maar het heeft te maken met wat er gebeurt als een model drie varianten van een "card"-component ziet en er één moet kiezen. Ik laat je zien hoe dat eruitziet en hoe je het oplost. Maar eerst hebben we tokens nodig die kunnen praten.

Tokens die Spreken: De Template die Alles Veranderde

Hier is de grootste doorbraak in deze hele workflow, en het is gênant eenvoudig.

Claude is een taalmodel. Jouw tokens zijn meestal nummers en hex-codes. Wanneer je een taalmodel niet-linguïstische input geeft, moet het betekenis afleiden. Geef je het linguïstische input, dan volgt het instructies. Dus de oplossing is: laat je tokens Engels spreken.

Ik gebruik een template met vier kolommen voor elke token. Naam. Light-waarde. Dark-waarde. Een één-zinsbeschrijving van wanneer je het gebruikt.

Hier is een stuk van mijn daadwerkelijke surface-tokens:

| Token                  | Light    | Dark     | When to use                                      |
|------------------------|----------|----------|--------------------------------------------------|
| surface-base           | #FFFFFF  | #0B0B0F  | The page background. Nothing sits behind this.   |
| surface-raised         | #F7F7F9  | #15151B  | Cards, list rows, anything one layer above base. |
| surface-elevated       | #FFFFFF  | #1D1D25  | Modals, popovers, menus — floating UI only.      |
| surface-sunken         | #F0F0F3  | #08080C  | Input fields, inset wells, read-only regions.    |
| surface-brand-subtle   | #EEF2FF  | #1A1D3A  | Brand-tinted backgrounds for promoted content.   |

Lees die "When to use"-kolom. Dat is het deel waar Claude om geeft. Dat is het deel dat een token verandert van een waarde in een instructie.

Doe dit voor elke tokencategorie — surface, content (tekst), border, action, status, elevation, radius, spacing, motion. Ja, ook spacing. space-2: 8px — tight rhythm inside dense components like form field groups is duizend keer nuttiger dan space-2: 8px.

Dit sluit aan bij waar de design systems-community in 2026 op uitkomt — semantische tokens met intentie in de naam verwerkt, gecombineerd met documentatie die doel beschrijft, niet uiterlijk. De twist die ik toevoeg is dat de documentatie bij de token moet leven, in het formaat dat Claude verwerkt, niet in een aparte wiki.

Sla deze tabel op als een markdown-bestand. design-tokens.md. Zet het in je projectrepo, direct naast je code. Dit bestand is nu je echte design system — de Figma-variabelen zijn slechts de gerenderde output.

Kleine kanttekening — ik heb dit wekenlang tegengehouden omdat ik dacht dat Claude gewoon de Figma-variabelebeschrijvingen direct kon lezen. Dat kan, technisch gezien. Maar de beschrijvingen die de meeste teams in Figma schrijven zijn óf leeg, óf geschreven voor designers ("primaire merk-kleur") in plaats van voor een model dat om 2 uur 's nachts op zaterdag tussen vijf blauwtinten moet kiezen. Schrijf ze opnieuw voor het model. Je designers kunnen ze nog steeds lezen. Niemand verliest.

Dat is de helft van het werk. De andere helft zijn componenten — en componenten zijn waar de workflow meestal strandt als je ze niet goed groepeert.

Componenten Groeperen Zodat Claude Niet in Paniek Raakt

Dit is iets wat ik op de harde manier heb geleerd. Als je Claude een design system met 140 componenten in een platte lijst geeft en vraagt om een scherm te bouwen, gedraagt hij zich als een aannemer die een bouwmarkt krijgt en de opdracht om een keuken te bouwen. Technisch gezien heeft hij alles wat hij nodig heeft. In de praktijk gebruikt hij de verkeerde hamer.

De oplossing: groepeer je componenten in semantische categorieën, met een aparte skill voor elke groep (of, als je het simpel wilt houden, één skill die alle groepen kent). De drie groeperingen die 90% van de product-UI dekken:

1. Formulierelementen. Invoervelden, tekstgebieden, selectiemenu’s, selectievakjes, keuzerondjes, schakelaars, datumkiezers, uploadzones voor bestanden, formulierregel, formulierfout, formulierhulpmelding. Elke variant. Elke status — standaard, focus, fout, uitgeschakeld, laden.

2. Navigatie. Topbalken, zijbalken, tabbladen, broodkruimels, paginering, terug-links, gesegmenteerde knoppen, stapsgewijze navigatie. Ook hier zijn statussen belangrijk — actief, hover, uitgeschakeld, ingeklapt.

3. Gegevensweergave. Tabellen, kaarten, lijstitems, statistiektegels, badges, tags, avatars, lege staten, laad-skeletten, grafieken, paginavoeten. Hier gaat het bij AI-gegenereerde schermen meestal mis, omdat het model standaard tabellen gebruikt waar een kaartgrid beter zou zijn, of statistiektegels waar een lijst beter past.

Voor elk component binnen elke groep documenteer je drie dingen voor Claude:

• Varianten — allemaal, met de variant-sleutelnamen exact zoals ze in je Figma-eigenschappenpaneel staan
• Props — elke boolean en enum die het component aanbiedt
• Gebruiksregel — één zin: "Gebruik de compacte variant voor dichte tabellen met meer dan 8 kolommen. Standaardvariant voor alles daarbuiten."

Die derde regel voorkomt dat Claude willekeurig een variant kiest omdat de naam leuk klinkt.

Dit is het patroon dat ik heb uitgewerkt in mijn eerdere Figma MCP-artikel, en het is het patroon dat ervoor zorgde dat de huidige workflow daadwerkelijk bruikbare eerste ontwerpen oplevert. Als je eerder design systems hebt gebouwd, weet je al dat het moeilijkste niet het definiëren van componenten is — het is documenteren wanneer je welke moet gebruiken. Die documentatie was altijd al waardevol voor mensen. Blijkt dat het voor modellen nóg waardevoller is.

Pro tip: als je meer dan één designer in je team hebt, zet ze samen in een ruimte en discussieer hardop over de gebruiksregels voordat je ze opschrijft. De discussie is de specificatie. De meningsverschillen die naar boven komen zijn precies de edge cases die Claude anders fout doet. Schrijf het overeengekomen antwoord op als regel.

Je zou denken dat we nu klaar zijn om te genereren. Dat zijn we niet. Er is nog één onderdeel, en dat is precies het stuk dat de meeste mensen volledig overslaan.

Stop met "Bouw een modal voor me" te zeggen — Laat Claude precies zien wat je bedoelt

De grootste fout die ik zie bij prompt-engineering in AI-designwerk is vaagheid die zich voordoet als beknoptheid. "Bouw een modal voor me." "Ontwerp een dashboard." "Maak een instellingen-scherm." Dit lijken scherpe prompts. Dat zijn ze niet. Ze zijn het prompt-equivalent van tegen een aannemer zeggen: "Bouw een keuken voor me" zonder plattegrond.

Wat wél werkt: koppel je componentvaardigheid aan specifieke voorbeeldschermen uit echte productie-apps.

Hier verdient Mobbin zijn abonnement. De bibliotheek van Mobbin bevat meer dan 600.000 schermen uit 1.200+ productie-apps (stand 2026) — wat betekent dat voor vrijwel elk UI-patroon dat je wilt bouwen, er ergens een uitgevoerde versie bestaat, gemaakt door een team dat er waarschijnlijk langer over heeft nagedacht dan jij tijd hebt.

Mijn eigen workflow, met het paywall-voorbeeld van afgelopen zaterdag:

1. Open Mobbin. Zoek op "paywall" binnen de categorie Finance.
2. Bekijk de paywall van Rocket Money. Bekijk die van Copilot. Bekijk die van YNAB.
3. Maak screenshots van twee of drie schermen die de toon treffen die ik zoek.
4. Voeg de screenshots toe aan Claude Code als beeldreferenties, samen met mijn tokens-vaardigheid en componenten-vaardigheid.
5. Prompt: "Bouw een paywall-scherm voor een finance-app. Stijl- en lay-outreferentie bijgevoegd. Gebruik onze design tokens en componenten. Output als HTML. Hero: jaarabonnement voor $79,99 met 'Bespaar 40%' label. Drie feature-rijen. Maandelijkse toggle. Vertrouwenslogo’s onderaan."

Die prompt bevat alles wat een designer nodig heeft. Referenties voor stijl en compositie. Specificiteit over de inhoud. Beperkingen op de bouwstenen. Geen ambiguïteit voor het model om op te lossen door te middelen.

Vergelijk dat met "bouw een paywall voor me." De eerste versie levert je een echt scherm. De tweede versie levert je een hallucinatie van een scherm.

(Als je Mobbin niet wilt, zijn de alternatieven in 2026 echt goed geworden — InspoAI biedt zoeken in natuurlijke taal, Appshots toont flows in plaats van losse schermen, Webframe is web-first. Ik blijf Mobbin gebruiken omdat de Finance- en B2B SaaS-categorieën daar dieper zijn. Jouw ervaring kan verschillen.)

Nog iets over referenties — gebruik er twee of drie, niet één. Met één referentie kopieert Claude het voorbeeld. Met drie referenties interpoleert Claude, wat dichter bij het gewenste resultaat komt. De kunst van de prompt zit in de afstand tussen de voorbeelden die je kiest.

Goed. Je hebt tokens. Je hebt gegroepeerde componenten met gebruiksregels. Je hebt voorbeeldschermen. Nu komen we bij het deel waarin je de machine daadwerkelijk installeert en gaat genereren.

De Figma Skills Installeren in Claude

Twee skills doen het echte werk in deze pipeline, en beide zijn in vijf minuten te installeren.

1. figma-use — dit is de fundamentele skill van Figma’s eigen MCP-server. Hiermee kan Claude schrijven naar je Figma-canvas: frames aanmaken, componenten instantiëren, variabelen toepassen, stijlen instellen. Alles wat in Figma terechtkomt, loopt via deze skill. De officiële documentatie van Figma beschrijft de installatie; de korte versie: kloon de skill-repo, zip deze, plaats hem in Claude’s skills-directory, herstart de sessie. Klaar.

2. Je eigen "Apply Design System" skill — dit is het maatwerk. Een enkel markdown-bestand dat je zelf schrijft. Het bevat:

• Een link of verwijzing naar je design-tokens.md-bestand
• Een link of verwijzing naar je components.md-bestand (gegroepeerd per categorie, met gebruiksregels)
• Een preambule die aan Claude uitlegt hoe deze toe te passen: "Gebruik altijd semantische tokens. Gebruik nooit ruwe hex-waarden. Kies altijd de componentvariant waarvan de gebruiksregel overeenkomt met de context. Vraag het als je twijfelt, in plaats van te gokken."
• Een lijst met verboden gedragingen: "Verzin geen nieuwe tokens. Maak geen nieuwe componenten aan. Gebruik geen gradients die niet in de tokenlijst staan. Rond hoeken niet af met willekeurige radiuswaarden."

Die preambule is belangrijk. Vooral de lijst met verboden gedragingen voorkomt de “gemiddelde internetoutput”-afwijking. Je leert het model niet creatief te zijn. Je leert het om gedisciplineerd te zijn. Gedisciplineerd is precies wat je wilt bij een eerste iteratie.

Lever beide skills aan. Herstart Claude Code. Controleer of ze geladen zijn.

Op dit punt heb je een Claude-instantie die je tokens in het Engels begrijpt, je componenten in context kent, referentieschermen heeft voor het gewenste patroon, en skills bezit om naar Figma te schrijven. Dit is de basisopstelling. Nu gaan we genereren — en hier komt het niet-voor-de-hand-liggende deel dat niemand je vertelt.

Wil je liever dat iemand deze hele pipeline van begin tot eind opzet voor een production design system — tokens-skill, component-skills, MCP-koppeling, teamuitrol — dat is een specifieke opdracht die ik aanbied. Je kunt zien wat ik gebouwd heb op fiverr.com/s/EgxYmWD.

Genereer lokaal in Claude Code eerst. Push daarna naar Figma.

Hier gaat het bij de meeste tutorials mis. Ze geven Claude één prompt, laten het direct naar Figma pushen, bekijken het resultaat en beginnen dan te itereren binnen Figma. Die workflow is traag, kost veel tokens en levert slechtere output op omdat elke iteratie via de MCP-server moet.

Het juiste patroon: itereren in Claude Code als HTML eerst. Pas naar Figma pushen als de HTML acceptabel is.

Mijn daadwerkelijke volgorde voor de finance paywall:

1. Prompt met alles geladen — tokens skill, components skill, drie Mobbin-referenties, de specifieke contentbrief. Vraag om HTML-output met Tailwind-klassen die aan mijn design tokens zijn gekoppeld.

2. Claude genereert de HTML inline in Claude Code. Ik render het in een browserpreview. Dat duurt ongeveer 8 seconden. Geen Figma round-trip.

3. Ik geef kritiek. Niet "maak het beter." Specifiek: "De hero CTA gebruikt action-primary-subtle maar dit is een conversieoppervlak — gebruik action-primary-bold. De feature-rij gebruikt space-3 voor spacing; dit patroon vereist space-4 omdat de iconen 24px zijn. De trust logo-rij mist een divider."

4. Claude werkt de HTML bij. Nog eens 6 seconden. Ik render opnieuw.

5. Ik herhaal die loop twee of drie keer. In deze fase is elke iteratie goedkoop — geen Figma, geen MCP payload, alleen tekst.

6. Als de HTML voor 90% klopt, vraag ik Claude om het naar Figma te pushen met de figma-use skill. Dit is de dure operatie, en ik doe het maar één keer per ontwerp.

7. Claude schrijft de frames in Figma. Echte componenten. Echte variabelen. Echte varianten. Responsief. Gelaagde namen. Auto-layout toegepast. Kleine missers in tekststijlen, waar ik zo op terugkom.

Dit local-first patroon halveert mijn iteratietijd ongeveer en verbruikt aanzienlijk minder tokens. Het levert ook betere output op, omdat ik aan het ontwerp werk terwijl het nog goedkoop is om te veranderen. Tegen de tijd dat ik naar Figma push, is het ontwerp in feite klaar — Figma is de bestemming, niet de werkplaats.

Eén specifiek punt om te benadrukken: als je om HTML-output vraagt, specificeer dan de token-namen in de prompt. "Gebruik klassen als bg-surface-raised, text-content-primary, rounded-radius-md." Zo dwing je Claude om de tokens als volwaardige onderdelen in de gegenereerde markup te behandelen. Je kunt deze later koppelen aan je eigen Tailwind-configuratie, of ze gewoon lezen als documentatie van welke tokens waar zijn gebruikt. Hoe dan ook, je krijgt controleerbare output.

Het Eerlijke Deel: Wat Deze Workflow Nog Steeds Fout Doet

Ik heb inmiddels tientallen schermen via deze pipeline opgeleverd. Het is een enorme verbetering ten opzichte van standaard prompten. Maar het is geen magie. Dit zijn de specifieke dingen die nog steeds misgaan, zonder iets mooier te maken dan het is.

Tekststijlen worden vaker gemist dan wat dan ook. Claude krijgt de spacing, de kleuren, de componenten, de layout perfect — en past dan text-body-md toe op een kop die eigenlijk text-heading-sm zou moeten zijn. Ik begrijp niet helemaal waarom typografie specifiek het zwakke punt is. Mijn werkhypothese is dat tekststijl-tokens subtielere intenties bevatten ("gebruik dit voor lijstkoppen met gemiddelde dichtheid") dan kleur- of spacing-tokens, en het model daardoor minder houvast heeft. Hoe dan ook: controleer typografie altijd handmatig in Figma. Reserveer drie tot vijf minuten per scherm voor deze correctie.

Auto-layout richting draait soms om. Een rij wordt een kolom, of andersom, vooral binnen geneste componenten. Meestal met één klik te fixen in Figma, maar het blijft een irritante belasting.

Merkpersoonlijkheid komt niet over. De workflow levert schermen op die correct zijn. Het levert geen schermen op die ziel hebben. Die extra 10% — de micro-interactie, die ene ongewone compositiekeuze, de typografische behandeling waardoor je app als de jouwe voelt — moet nog steeds van een mens komen. Deze workflow brengt je tot een gepolijste, systeemconforme eerste versie. Het brengt je niet tot kunst.

Tokens worden soms letterlijk toegepast in plaats van semantisch. Als Claude surface-raised: #F7F7F9 in mijn tokensbestand ziet, schrijft hij soms #F7F7F9 direct in de HTML in plaats van bg-surface-raised. De preambule die dit verbiedt helpt, maar lost het niet volledig op. Controleer de gegenereerde code.

Licht/donker-pariteit vereist handmatige controle. Zelfs als beide waarden in je tokens zijn gedefinieerd, kiest Claude soms een combinatie die werkt in licht, maar faalt op WCAG-contrast in donker. Ik heb dit gecontroleerd op de paywall — de trust-logo-rij haalde 4.5:1 contrast in light mode, maar zat op 3.2:1 in dark. Doe een contrastcheck voor je live gaat; de baseline voor 2026 blijft 4.5:1 voor bodytekst.

Als ik deze tekortkomingen zou opsommen zonder de context van hoeveel beter de workflow met structuur is, zou het erger klinken dan het is. Dus laat ik het omdraaien.

Wat Verandert Er Echt: Eerste-Pass Kwaliteit En Opruimtijd

Hier is het echte verschil, waargenomen in mijn eigen projecten gedurende de afgelopen acht weken. Ik geef je geen verzonnen percentages, want ik houd dit niet bij in een database. Wat ik wél bijhoud, is hoeveel schermen zonder significante herwerking worden opgeleverd, en het patroon is consistent genoeg dat ik erop vertrouw.

Voor deze workflow: de eerste output van standaard prompts vereiste meestal een structurele herbouw. Componenten waren fout, de hiërarchie klopte niet, de helft van de tokens werd niet eens toegepast. Een realistisch pad naar een verzendbaar scherm was 45–90 minuten opruimen per scherm, en meestal bouwde ik grote delen met de hand opnieuw.

Na deze workflow: de eerste output is structureel correct. Tokens zijn toegepast. Componenten kloppen. De layouthiërarchie is bijna definitief. Opruimen bestaat vooral uit tekststijlen, één of twee aanpassingen in de spacing, en een contrastcontrole. Een realistisch pad naar een verzendbaar scherm is 10–15 minuten opruimen per scherm, en ik ben aan het bewerken in plaats van herbouwen.

De grootste winst is consistentie. Een teamlid dat dezezelfde setup volgt, levert schermen op die eruitzien alsof ze uit hetzelfde systeem komen, omdat dat ook zo is. Voor gestructureerde skills hadden AI-gegenereerde schermen een soort entropie — elke generatie week een beetje af. Na gestructureerde skills wordt die afwijking begrensd door de systeemomschrijving zelf.

Voor teams die met design systems werken, weerspiegelt dit patroon wat Figma eerder dit jaar documenteerde in hun AI-to-Figma workflow voor design systems — structureer het systeem, en laat de agents binnen die structuur werken. De verbetering komt niet door slimmere modellen. Het komt door strakkere rails.

Er is nog iets dat het benoemen waard is. Het uur dat je besteedt aan het schrijven van tokenbeschrijvingen en componentgebruiksregels, betaalt zich terug elke keer dat je een scherm genereert. Na het vijfde of zesde scherm is de workflow per saldo ruimschoots positief. Voor het vijfde scherm ben je aan het investeren. Stop niet na scherm twee. Stop na scherm tien als het dan nog steeds niet werkt, en tegen die tijd weet je precies welk deel van de setup strakker moet.

De Paywall, Afgerond

De paywall die mijn zaterdag opslokte aan het begin van dit artikel, werd de volgende ochtend opnieuw opgebouwd in ongeveer 40 minuten, inclusief het werk aan tokens en componenten dat ik de eerste keer had moeten doen. De uiteindelijke versie gebruikte mijn eigenlijke action-primary-bold voor de CTA, de juiste surface-elevated voor de plankaart, het specifieke space-4 ritme voor de feature-rijen. De trustlogo-scheiding stond er. Zowel licht als donker voldeden aan het contrast. Tekststijlen hadden één opschoningsronde nodig aan de Figma-kant. Verstuurd.

De les is niet dat AI-design nu werkt. De les is dat AI-design werkt wanneer je je design system als trainingsdata behandelt en lokaal iteratief werkt voordat je het op het canvas zet. Het werkt wanneer je stopt met hopen dat het model je gedachten leest en begint te beschrijven wat er in je hoofd zit, zo specifiek dat het model het niet meer hoeft te raden.

Dit is wat ik wil dat je vandaag doet — niet volgende week, niet nadat je nog drie artikelen hebt gelezen. Open je design system. Kies één tokencategorie. Surface, content of spacing. Schrijf voor elke token in die categorie een "wanneer te gebruiken"-beschrijving van één zin. Dat is je eerste stap. Dat is de hele doorbraak. Doe dat vandaag voor één categorie en je bent verder dan de meeste teams. Doe het deze week voor elke categorie, en je hebt een design system dat een model daadwerkelijk kan toepassen.

De volgende paywall die je bouwt, slokt je zaterdag niet op. Die kost je veertig minuten. En die veertig minuten zijn vooral typografie-opschoning, wat je — eerlijk gezegd — toch al zou doen.

Veelgestelde Vragen

Heb ik de betaalde Figma MCP-server nodig voor deze workflow?

Nee. De kern van de Figma MCP-server en de fundamentele figma-use skill zijn gratis te installeren. Voor sommige schrijfoperaties naar gedeelde teambibliotheken is een betaald Figma-abonnement vereist, maar solo werken aan conceptbestanden werkt gewoon op het gratis niveau. Zie het implementatiegedeelte hierboven voor de volledige setup.

Werkt dit met Codex of andere niet-Claude modellen?

Gedeeltelijk. De Figma MCP-server ondersteunt meerdere MCP-clients, waaronder Codex, dus de Figma-kant werkt. Het skill-laadpatroon is Claude-specifiek — Codex gebruikt zijn eigen extensieformaat. Het kernidee (gestructureerde tokens plus component-skills plus referentieschermen) is model-agnostisch en overdraagbaar naar elke capabele code-agent.

Hoe lang duurt het om design token- en component-skills de eerste keer op te zetten?

Reken op drie tot zes uur gefocust werk voor een middelgroot systeem, ervan uitgaande dat je tokens en componenten al ergens zijn gedocumenteerd. De tijdsinvestering zit vrijwel volledig in het schrijven van de "wanneer te gebruiken"-beschrijvingen — het daadwerkelijk aanmaken van de skill-bestanden gaat snel.

Kan Claude nieuwe componenten maken als ik daarom vraag?

Ja, maar je moet dit in je skill-preambule verbieden voor productiegebruik. Claude toestaan om spontaan componenten te verzinnen ondermijnt de consistentie van het systeem — precies waar je dit voor doet. Als er echt een nieuw component nodig is, ontwerp het dan eerst bewust in Figma, voeg het toe aan je component-skill en genereer er daarna mee.

Wat is de meest gemaakte fout bij het starten van deze workflow?

Het overslaan van de "wanneer te gebruiken"-beschrijvingen bij tokens. Teams kopiëren token-namen en -waarden, denken dat dat voldoende is, en vragen zich af waarom het resultaat nog steeds generiek oogt. De beschrijvingen zijn juist het deel dat een token verandert van data naar instructie. Zonder die beschrijvingen ben je weer terug bij standaard prompting, maar dan met extra stappen.

Laten We Samenwerken

Wil je AI-systemen bouwen, workflows automatiseren of je technische infrastructuur opschalen? Ik help je graag.

• Fiverr (maatwerk & integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise-oplossingen): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io