Waarom raadt een AI je componenten mis?

Een AI-agent die Figma-designs omzet naar code heeft één groot probleem: hij ziet de componenten in je design, maar weet niet hoe ze in de echte codebase heten of werken. Dus gaat hij raden. Soms raadt hij goed. Vaker bouwt hij iets na van primitieven, terwijl je al een kant-en-klaar component had liggen.

Dit is iets waar ik eerlijk gezegd te lang mee heb rondgelopen. Ik werkte met Figma en Claude voor design-to-code werk, en de output was wisselend. Soms perfect, soms een handgemaakte versie van een component die we al hadden. Het probleem zat niet in het model. Het zat in de context die ik meegaf.

Code Connect is de oplossing die Figma biedt voor dit probleem. Het is een koppeling (mapping) tussen een component in Figma en zijn tegenhanger in de code. Vergelijk het met een woordenboek: de AI ziet ‘Stepper’ in het design en slaat op in het woordenboek op wat dat in jouw codebase betekent, inclusief alle properties en gebruik.

Zonder dat woordenboek gaat de agent gokken. En bij complexe componenten, zoals een Stepper met tientallen properties, levert dat bijna altijd rommel op. Met een goede design system opzetten-aanpak leg je in één tekstbestand vast hoe jouw merk eruitziet, dat is een laagdrempelig startpunt als je nog geen volledig design system hebt.

Wat leverde 22% tijdsbesparing op in de praktijk?

Coinbase testte Code Connect in een gecontroleerde opzet: hetzelfde design, dezelfde prompt, hetzelfde model, drie keer uitgevoerd. Met en zonder Code Connect. Het resultaat was consistent: elke run met Code Connect was goedkoper, sneller en nauwkeuriger dan zonder. Gemiddeld 22,5% lagere kosten en 22% kortere implementatietijd.

De testopzet was slim. Ze gebruikten een design dat niet te simpel en niet te complex was: een mix van componenten, inclusief een paar lastige gevallen zoals de Stepper (complex, veel properties) en icoon- en illustratienamen (die agents notoir slecht raden).

Dat laatste punt trof me. Agenten hallucineren icoon- en illustratienamen. Ze verzinnen namen die niet bestaan. Na het instellen van Code Connect verdween dat probleem volledig. Niet minder vaak. Verdwenen.

De verklaring is logisch: de agent hoeft niet meer te zoeken en te raden welk icoon er bedoeld wordt. De mapping vertelt het hem direct. Minder zoekwerk betekent minder tokens, en minder tokens betekent lagere kosten en kortere looptijd. Dit is precies waarom ik nu bij elk project als eerste check of het design system goed is opgezet voordat ik een AI-agent op een design loslaat. Een slordig design system is een dure agent.

Overigens controleerde de test ook voor prompt caching, een techniek waarbij eerder verwerkte context hergebruikt wordt. Dat kan resultaten vertekenen als je het niet uitschakelt. Ze deden dat wel, wat de uitkomsten betrouwbaarder maakt.

Agent skills vs. Code Connect: doen ze hetzelfde?

Nee, en dat onderscheid is belangrijk. Agent skills vertellen een AI hoe hij iets moet bouwen: welke patronen te kiezen, welke componenten te vermijden, hoe je design tokens gebruikt. Code Connect geeft de agent context over wat er beschikbaar is. De twee vullen elkaar aan, ze vervangen elkaar niet.

Dit is een inzicht dat ik zelf ook pas later begreep. Ik dacht dat goede instructies (agent skills of een systeem-prompt) genoeg waren om een AI goed te laten presteren op design-to-code taken. Dat klopt deels. Maar instructies over hoe je iets bouwt helpen niet als de agent niet weet wat er al gebouwd is.

De vergelijking die ik gebruik: agent skills zijn de werkwijze van een nieuwe collega, Code Connect is het onboarding-document met alle bestaande componenten. Je hebt beide nodig.

Interessant is ook de langetermijnvisie hierachter. Naarmate AI-modellen beter worden, hebben ze minder expliciete instructies (skills) nodig om goede keuzes te maken. Maar de kwaliteit van de context, weten welke componenten er zijn en hoe ze werken, blijft altijd relevant. Dat maakt Code Connect eigenlijk toekomstvaster dan agent skills.

Wil je begrijpen hoe Figma Skills werken als herbruikbare AI-instructies? Lees dan hoe Figma Skills designers helpen met AI-workflows als goed startpunt om het verschil voelbaar te maken.

Wat moet je nu doen als je een design system hebt?

Check of je componenten in Figma gekoppeld zijn aan de code via Code Connect. Zijn ze dat niet, of zijn de mappings verouderd? Dan geef je elke AI-agent die je gebruikt een slechte startpositie. Updaten hoeft niet per hand: je kunt een agent de mappings laten schrijven op basis van een lijst componenten.

Het Coinbase-team had hetzelfde probleem: bestaande mappings waren verouderd en nieuwe componenten hadden helemaal geen template. Ze losten dat op door een agent in te zetten die de mappings parallel bijwerkte. In vier uur hadden ze volledige dekking voor hun design system.

Dat is de aanpak die ik zou volgen. Niet handmatig elke component doorlopen, maar een gestructureerde lijst maken en een agent het werk laten doen. Let op: de output moet je nog wel controleren. Een agent die mappings schrijft kan fouten maken, zeker bij complexe componenten.

Heb je nog geen design system? Dan is dit een goed moment om na te denken over hoe je dat opzet. Niet als luxe voor grote teams, maar als fundament voor alles wat je met AI bouwt. Met een DESIGN.md leg je in één tekstbestand vast hoe jouw merk eruitziet, dat is een laagdrempelig startpunt als je geen volledig design system hebt.

Voor wie WordPress gebruikt en wil weten hoe AI past in het bredere plaatje van webdesign en development: AI inzetten voor WordPress-code begrijpen en verbeteren laat zien hoe je AI als sparringpartner gebruikt in plaats van als schrijfmachine.

Wat zijn Figma Skills precies?

Figma Skills zijn markdown-bestanden met instructies die de ingebouwde AI-agent van Figma uitvoert. Je roept ze aan met een slash-commando, zoals /component-handoff of /ui-state-expander. Ze werken als persoonlijke sneltoetsen voor taken die je anders steeds opnieuw handmatig zou doen. Je schrijft ze zelf, of je gebruikt er een van de Figma Community.

Een Skill is eigenlijk een gestructureerde prompt die je één keer schrijft en daarna eindeloos hergebruikt. Het klinkt technisch, maar het zijn gewoon tekstbestanden in markdown-formaat, dezelfde opmaaktaal als in veel notitie-apps. Je hoeft geen developer te zijn om ze te begrijpen of te schrijven.

Wat me opvalt aan dit systeem: het legt voor het eerst de designkennis van een individuele ontwerper vast in een deelbare vorm. Normaal zit die kennis in iemands hoofd. Nu zit het in een bestand dat iedereen in het team kan gebruiken. Dat is een fundamenteel ander idee dan een template of een component library.

Je maakt een Skill door de agent te vragen er een te schrijven op basis van een frame in je design of via specifieke stappen die je opgeeft. Daarna kun je hem direct testen, bijsturen en aanpassen. Als je de manier waarop Figma Weave merkstijlen vastlegt al interessant vond, dan is dit de volgende stap in diezelfde richting.

Welke 10 Skills zijn het meest nuttig voor een designer?

De Figma Community heeft tientallen Skills gepubliceerd. Tien daarvan springen eruit omdat ze concrete tijdwinst opleveren: van automatische componentdocumentatie tot een volledige UI-state-checker en een ingebouwde design review op basis van UX-heuristieken.

Hieronder de tien Skills die de meeste designpijn wegnemen, met wat ze concreet doen:

• /component-handoff: genereert automatisch een documentatieframe met naam, versie, variant-grid, do’s en don’ts en anatomie van een component. Wat eerder een uur kostte, duurt nu een klik.
• /ui-state-expander: pakt een scherm en vult alle ontbrekende states in, zoals loading, empty, error, disabled en edge cases. Inclusief copy, transitions en implementatienotes voor de developer.
• /analyze-components: crawlt een pagina, vindt orphans, duplicaten en naamfouten, repareert ze automatisch en schrijft een auditrapport op het canvas.
• /superfuture-design-review: beoordeelt een bestand op UX-heuristieken, toegankelijkheid en visuele hiërarchie, met een stoplicht-systeem: rood voor blockers, geel voor aanbevelingen, groen voor wat al werkt.
• /create-color: mapt alle fills, strokes en shadows in een component naar design tokens of styles, en markeert hard-gecodeerde kleuren die nog vervangen moeten worden.
• /find-animation-opportunities: scant designs op plekken die wel of niet zouden moeten animeren, met exacte waarden en concrete aanbevelingen.
• /camera-pan-and-zoom: bouwt een camera-rig, een geneste laagstructuur die echte camerabeweging nabootst, om geselecteerde content en animeert die als een motion director.
• /better-interface: geeft de agent een persoonlijk regelboek voor interface-craft, met standaarden voor typografie, layout, toegankelijkheid en productteksten.
• /usability-test-guide: genereert een discussiegids voor usability-tests op basis van een designflow, met open vragen direct op het canvas naast elk frame.
• /xray-scan: zet een foto of tekstbeschrijving om naar een radiografisch beeld in twee afwerkingen, handig voor creatieve collages en moodboards.

Naar mijn idee zijn /component-handoff en /ui-state-expander de twee die direct rendement opleveren voor iedereen die regelmatig designs overdraagt aan developers. De rest is waardevol, maar afhankelijk van je specifieke workflow. Bekijk ook hoe AI Figma-designs omzet naar werkende code voor een aansluitende aanpak.

Hoeveel tijd bespaar je er écht mee?

Componentdocumentatie die handmatig een uur kost, doet /component-handoff in één klik. Een volledige UI-state-check die je normaal vergeet tot de developer erom vraagt, doet /ui-state-expander in enkele minuten. De tijdwinst zit niet in spectaculaire taken, maar in de dingen die je anders uitstelt.

Eerlijk gezegd was ik sceptisch toen ik voor het eerst hoorde over ‘AI die je designtaken overneemt’. Mijn eerste reactie: dat klinkt als een belofte die in de praktijk tegenvalt. Maar de Skills-aanpak werkt anders dan een generieke AI-chat, en dat maakt het verschil.

Het verschil is specificiteit. Een generieke AI weet niet hoe jouw team componenten documenteert, welke states jij altijd vergeet of welke kleuren hard-gecodeerd zijn in je design system. Een Skill wél, omdat jij die kennis er zelf in hebt gestopt. Of iemand anders dat voor je heeft gedaan en het gedeeld heeft in de Community.

De concrete tijdwinst per Skill is moeilijk te generaliseren, want die hangt af van hoe ingewikkeld je design system is. Maar de /analyze-components-skill pakt het soort werk aan dat je normaal uitstelt tot het echt niet meer kan. Dat soort uitgesteld werk kost uiteindelijk meer tijd dan de taak zelf.

Voor wie website-toegankelijkheid serieus neemt, is /superfuture-design-review interessant: die checkt ook op toegankelijkheidsstandaarden als onderdeel van de review.

Zelf een Skill schrijven: zo werkt dat in de praktijk

Je vraagt de Figma-agent een Skill te maken op basis van een frame of een beschrijving van je werkwijze. De agent schrijft een eerste versie, jij test die, past aan en slaat op. Je kunt de markdown ook direct bewerken als je precies weet wat je wilt.

Het proces is minder technisch dan het klinkt. Je hoeft geen code te schrijven. Je beschrijft in gewone taal wat je wilt dat de Skill doet, de agent vertaalt dat naar gestructureerde instructies, en jij controleert of het klopt. Klopt het niet helemaal? Dan zeg je wat er anders moet, net als in een gewone chatconversatie.

Wat ik een slim detail vind: je kunt een bestaand designframe gebruiken als referentie. Je wijst de agent op een component die je altijd op een bepaalde manier documenteert, en vraagt hem daar een Skill van te maken. Zo leg je werkwijzen vast die anders alleen in je hoofd zitten.

Let op: Skills zijn momenteel beschikbaar voor Full seat-gebruikers op Professional, Organization en Enterprise plannen. Collab-, Dev- en View-seats kunnen de agent gebruiken in hun drafts. Tijdens de open beta is het gratis. Wat het na de beta kost, is nog niet bekendgemaakt.

Als je al werkt met AI-tools die Figma-designs omzetten naar code, dan past dit systeem goed in diezelfde workflow. Je legt je designkennis vast in Skills, en je legt je code-kennis vast in de tools die de output verwerken.

Het probleem: AI-tools missen context van jouw merk

Je laat een AI een banner of UI maken en krijgt drie keer iets anders terug. Andere kleur, ander gevoel. Niet jouw stijl. Dat is geen bug. AI-tools werken op basis van wat je ze geeft. Zonder merkinformatie gokken ze op iets generieks.

Bij mijn klanten zie ik dit elke week. Vorige week kwam een klant in de hospitality bij me met drie social-posts uit een AI-tool: drie keer dezelfde prompt, drie keer een ander oranje. Hij dacht eerst dat het aan zijn ogen lag , tot ik de hex-codes naast elkaar zette en hij het verschil zwart-op-wit zag.

De fout zit niet in de tool, hij zit in het gebrek aan context. Bij Midjourney, Claude, ChatGPT en Figma AI werkt het allemaal zo. Geen merkinformatie? Dan gokken ze. DESIGN.md vult die context in één keer in en houdt hem voor elke volgende prompt vast.

Wat DESIGN.md is en waarom het werkt

DESIGN.md is een tekstbestand met je merkinfo in een formaat dat AI direct begrijpt. Geen formeel document. Geen technische specificatie. Kleuren als hex-codes, fontnamen, een paar stijlsteekwoorden, korte componentbeschrijvingen. Eén tot twee pagina's max.

Ik gebruik dit zelf voor elk klantproject sinds een half jaar. Het scheelt me makkelijk een uur per ontwerpronde aan corrigeren en herhalen. Werkt in elke AI-tool die tekst als input accepteert: ChatGPT, Claude, Midjourney, Figma AI, Cursor, Lovable.

Het bestand zelf hoef je nergens te uploaden. Je plakt de inhoud aan het begin van je prompt, daarna pas komt je opdracht. Resultaat: consistente output die er elke keer hetzelfde uitziet.

De vier basissecties die je opschrijft

Vier secties zijn genoeg. Kleuren als hex-codes (niet "donkerblauw" maar #0A1F44). Fonts met gewicht ("Inter Regular 400"). Drie tot vijf stijlsteekwoorden. Korte componentbeschrijvingen voor je terugkerende UI-elementen.

Concrete waarden zijn het belangrijkst. Niet “warm oranje” maar #F5821F. Niet “modern blauw” maar #0A1F44. AI vertaalt jouw woorden naar pixels, en die vertaling werkt alleen voorspelbaar bij exacte waarden.

Mijn eigen fout in het begin: te veel willen vastleggen. Ik schreef pagina’s vol met uitzonderingen, edge cases en gedragsregels per component. De AI raakte juist meer in de war en mengde regels door elkaar. Sinds ik me beperk tot een halve A4 met alleen de essentials, werkt het tien keer beter.

Voor componenten geef je één regel per type: “Primaire knop: oranje achtergrond, witte tekst, 4px border-radius, geen schaduw.” Dat is genoeg. Te veel detail laat de AI dwalen.

Werkend voorbeeld: DESIGN.md voor een bouwbedrijf

Dit is de DESIGN.md die ik gebruik voor een klant in de bouw. Concreet, in dezelfde structuur die ik altijd hanteer. Gebruik 'm als template: vervang de waarden door die van jou en je hebt binnen tien minuten een werkend bestand.

De fictieve klant heet “Bouwbedrijf Janssen”. De structuur hieronder werkt 1-op-1 voor elke andere branche, alleen de waarden verschillen.

# DESIGN.md ,  Bouwbedrijf Janssen

## Kleuren
- Primair: #1B3A57 (donkerblauw, voor headers en knoppen)
- Accent: #E8A33D (warm geel-oranje, voor CTA's en hover-states)
- Tekst: #1A1A1A op #FFFFFF
- Achtergrond licht: #F5F2ED (gebroken wit, geen plat wit)
- Lijnen en borders: #D4CFC4

## Typografie
- Headings: Montserrat SemiBold 600
- Body: Inter Regular 400
- Captions: Inter Light 300, 14px
- Knoppen: Montserrat Medium 500, all caps

## Stijl in steekwoorden
Solide, ambachtelijk, betrouwbaar, ruime witregels, geen schaduwen, foto's altijd warm-getint.

## Componenten
- Primaire knop: #1B3A57 achtergrond, witte tekst, 4px border-radius, hover #E8A33D
- Secundaire knop: transparant, 1px border #1B3A57, blauwe tekst
- Kaart: #FFFFFF achtergrond, 8px border-radius, 1px border #D4CFC4, geen schaduw
- Foto's: altijd 16:9, warme tint via 5% sepia-overlay

## Tone of voice
Direct, geen jargon, jij/je-vorm, korte zinnen. Vermijd: "innovatief", "passie", "kwaliteit". Gebruik: "we bouwen", "we leveren op tijd".

Plak deze inhoud aan het begin van je prompt en je AI-tool weet direct wat hij wel en niet moet doen. Een UI-generator levert nu een knop op met #1B3A57, niet met een willekeurig blauw.

Hoe je DESIGN.md in de praktijk gebruikt

In de praktijk: open je AI-tool, plak de DESIGN.md, daarna pas je opdracht. Werkt voor afbeeldingen, UI, code en zelfs teksten als je een tone of voice-sectie toevoegt. Maak twee versies: een korte voor snelle prompts, een complete voor diepere opdrachten.

Voorbeeld voor een UI-generator: “[DESIGN.md inhoud] Maak nu een contactformulier met deze stijl. Velden: naam, e-mail, bericht.” Je krijgt een formulier in jouw kleuren, met jouw font, met de juiste border-radius. Geen willekeur meer.

Voor afbeeldingsgeneratoren werk je met een ingedikte versie. Niet de hele DESIGN.md, alleen de relevante regels: primaire en accent-kleur, drie stijl-steekwoorden, eventuele foto-stijl. Vier regels meegeven werkt vaak beter dan twintig.

Voor AI-codeertools zoals Cursor of Claude Code sla je het bestand op in je projectmap. Tools die met repositorybestanden werken pikken het automatisch op als context. Wat ik bij klanten doe: bouw DESIGN.md in de eerste week van een project en sla hem op naast de README. Geen overleg meer over kleuren, geen “welk geel was het ook alweer?”. Het bestand is de bron van waarheid.

Wat een Figma Weave-workflow concreet is

Een Weave-workflow is een soort recept: een keten van AI-acties waar je inputs aan geeft en een visueel resultaat uit krijgt. De workflow zelf bevat al je merkkleuren, fonts en stijl-aanwijzingen, dus je hoeft die niet steeds opnieuw te tikken.

Concreet bij een klant: ik bouwde een workflow genaamd Instagram-post Bouwbedrijf Janssen. Inputs: een productfoto en een korte tekst. Outputs: drie variaties op de social-post in de huisstijl, met de juiste typografie, kleurpaletten en een licht warme tint over de foto.

De klant gebruikt die workflow zelf elke week. Hij hoeft niet te weten wat een hex-code is of hoe een prompt werkt. Hij upload een foto, typt zijn tekst, krijgt drie posts. De stijl klopt elke keer.

Wanneer Weave bij mij echt productief is

Voor herhaalbaar werk waar consistentie belangrijker is dan eenmalige creativiteit. Social media posts, productfoto-varianten, marketing-banners op standaard formaten. Voor unieke campagnes met een eigen stijl is een gewone Figma-sessie sneller.

Bij mijn klanten zie ik twee groepen: kleine bedrijven die wekelijks 5 social-posts willen, en e-commerce-klanten die voor elk product een banner willen in de huisstijl. Voor beide groepen is Weave een gigantische tijdwinst. Wat vroeger een halve dag werk was, is nu een uur.

Wat het minder geschikt maakt: éénmalige campagne-uitingen die juist opvallen omdat ze van de norm afwijken. Daar zit Weave je in de weg, want hij dwingt je in een vooraf-gedefinieerde stijl. Voor zulke gevallen pak ik een gewone Figma-sessie zonder workflow.

Hoe ik een Weave-workflow opzet bij een nieuwe klant

Eerst een DESIGN.md-achtige basis vastleggen (kleuren, fonts, stijlregels), daarna een Weave-workflow per use-case bouwen, dan testen met de klant zelf en finetunen. Drie tot vijf workflows is meestal genoeg voor een MKB-klant.

Mijn vaste aanpak in vijf stappen: één: bekijk welke visuele uitingen de klant wekelijks of maandelijks nodig heeft. Twee: leg de huisstijl vast in een document zoals DESIGN.md. Drie: bouw één workflow voor de meest voorkomende uiting (vaak Instagram of LinkedIn). Vier: laat de klant zelf drie posts genereren en kijk waar de output afwijkt van wat zij willen. Vijf: finetune de workflow tot de output 80 procent goed is zonder handmatig nawerk.

Die laatste stap is belangrijk. Een workflow op 100 procent afstellen is onmogelijk en zinloos: er blijft altijd handwerk over. Maar 80 procent automatisch met 20 procent finetune is veel beter dan 0 procent automatisch.

Wat Weave nog niet goed doet

Werkelijk grafische originaliteit en ongewone composities. Plus: vergankelijke trends. Workflows zijn statisch, maar trends in social design veranderen om de zes maanden. Wie zijn workflows een jaar lang niet bijwerkt, valt achter.

Wat ik bij klanten merk: een workflow die zes maanden geleden modern aanvoelde, oogt na een jaar lichtelijk gedateerd. De typografie-trends, het soort animatie, de kleurnuances, alles schuift langzaam op. Mijn aanbeveling aan klanten: één keer per twee kwartalen een halve dag besteden aan workflows opnieuw afstellen.

Voor de echte vrijheid in design pak ik bij klantcampagnes nog steeds een blanco Figma-bestand. Weave is voor het werk dat herhaalt, niet voor het werk dat opvalt.

Hoe ik dit voor het eerst gebruikte

Een klant stuurde me een Figma-link met een dashboard-design dat ik in React moest bouwen. In plaats van handmatig elke component over te tikken, plakte ik de link in Claude met de instructie om het op te bouwen volgens mijn vaste stack. Tien minuten later had ik 80 procent werkende code.

De setup is simpel als je het eenmaal hebt gedaan. Je gebruikt de Figma MCP-server (open-source, een halve dag installatie) of je exporteert het frame als afbeelding plus design-tokens. Claude heeft dan toegang tot de structuur van het design en de specifieke kleuren, fonts en spacing.

De winst van die eerste ervaring: een dashboard waar ik normaal een halve werkdag mee bezig was, was binnen anderhalf uur live. Niet pixel-perfect, niet helemaal volgens mijn smaak, maar werkend en op klanten-stijl. De rest was handmatig finetunen.

Wanneer dit echt goed werkt

Bij design systemen met duidelijke components, herhaalbare patterns en consistente naamgeving. Een Figma-bestand met losse "schermen" zonder component-structuur geeft veel slechtere code. Hoe schoner de Figma, hoe beter de output.

Wat de output kwalitatief onderscheidt: of de designer in Figma met components heeft gewerkt of met losse rechthoeken en tekstvelden. Een Figma-bestand met “Button/Primary”, “Card/Default” en “Input/WithLabel” als components geeft Claude direct herhaalbare React-componenten terug. Een bestand met 20 versies van een knop die elk net iets anders zijn, geeft 20 versies van dezelfde knop in code.

Mijn tip aan klanten en designers: investeer in de Figma-setup vóór de developer eraan komt. Een halve dag componenten netjes inrichten in Figma scheelt later twee dagen handmatige React-arbeid. Dat is een hele goede ROI.

Wat Claude nog niet goed doet

Animaties, complexe state-handling, en alles wat dynamisch reageert op data. Een Figma toont meestal een statische staat. Claude raadt redelijk goed wat dynamisch zou moeten zijn, maar voor productie-kwaliteit is dat altijd handmatig nawerk. Plus: design-tokens vertaalt hij niet altijd naar jouw setup.

Concreet bij een laatste project: Claude zette de visuele kant van een filters-paneel goed neer, maar de logica voor het opslaan van de filterstatus, het synchroniseren met URL-params en het handelen van loading-states moest ik zelf bouwen. Dat is werk dat in geen enkele Figma staat, dus dat is logisch.

Wat ik er bij klanten over zeg: gebruik dit voor de eerste 80 procent van het visuele werk. De laatste 20 procent (interactie, edge-cases, prestatie-optimalisatie) blijft mensenwerk. Wie deze grens niet trekt, levert demo-kwaliteit op aan klanten en raakt klant en project allebei kwijt.