Design Tokens in 2026: Figma en de productie-interface synchroniseren zonder handmatige correcties

Een designsysteem wordt moeilijk te onderhouden wanneer dezelfde beslissing op meerdere losstaande plaatsen bestaat. Een merkkleur kan in Figma bijvoorbeeld één hexadecimale waarde hebben, in CSS een andere en in een mobiele applicatie nog een oudere versie. Hetzelfde probleem kan zich voordoen bij afstanden, hoekafrondingen, typografie en componentstatussen. Design tokens verminderen deze duplicatie door belangrijke ontwerpbeslissingen vaste namen en herbruikbare waarden te geven. In 2026 is de koppeling tussen ontwerp en productie aanzienlijk praktischer dan enkele jaren geleden: Figma-variabelen kunnen tokens vertegenwoordigen, de Design Tokens Community Group heeft haar eerste stabiele specificatie uitgebracht en tokenbestanden kunnen in gestandaardiseerde formaten tussen ontwerp- en ontwikkelprocessen worden uitgewisseld. Het doel is niet om ontwerpers of ontwikkelaars uit het proces te halen. Het gaat erom te voorkomen dat zij steeds opnieuw waarden tussen tools moeten kopiëren en voorspelbare inconsistenties handmatig moeten corrigeren.

Waarom Design Tokens de verbinding tussen Figma en productie zijn geworden

Een design token is een benoemde ontwerpbeslissing en niet simpelweg een opgeslagen kleur of getal. In plaats van een ontwikkelaar bijvoorbeeld te vertellen dat een knop #2563EB gebruikt, kan een designsysteem een primitieve kleur definiëren en die vervolgens via een semantisch token zoals colour/action/primary gebruiken. Dat onderscheid is belangrijk, omdat de semantische naam beschrijft waarom de waarde wordt gebruikt. Als de merkkleur later verandert, kan het team het onderliggende token aanpassen in plaats van honderden frames, componenten en stylesheets te doorzoeken naar een oude hexadecimale code. Dezelfde aanpak werkt voor afstanden, dimensies, typografische waarden, randen en veel andere terugkerende ontwerpbeslissingen.

Figma-variabelen bieden een praktische manier om dit model aan de ontwerpzijde te vertegenwoordigen. Figma ondersteunt momenteel kleur-, nummer-, string- en booleaanse variabelen, terwijl variabelen ook naar andere variabelen kunnen verwijzen. Daardoor kunnen ruwe waarden worden gescheiden van de beslissingen waarin ze worden toegepast. Een blauwe waarde kan in een primitieve collectie staan, terwijl interface-elementen verwijzen naar semantische variabelen zoals text/link/default of background/action/primary. Figma ondersteunt daarnaast modes, waardoor de waarde achter een variabele afhankelijk van de context kan veranderen. Lichte en donkere thema’s zijn het meest voor de hand liggende voorbeeld, maar modes kunnen ook verschillende merken, apparaatformaten of andere gecontroleerde variaties vertegenwoordigen zonder dat voor elke situatie een aparte set componenten nodig is.

De belangrijkste verandering voor 2026 is dat de uitwisseling van tokens niet langer volledig afhankelijk hoeft te zijn van eigen conventies. De Design Tokens Community Group publiceerde op 28 oktober 2025 haar eerste stabiele specificatie, versie 2025.10. Figma introduceerde vervolgens native import en export van design tokens op basis van het DTCG-formaat. Een team kan tokengegevens daardoor opslaan in gestructureerde JSON in plaats van voor elke tool in de workflow een ander formaat te bedenken. Dat maakt synchronisatie op zichzelf nog niet automatisch, maar geeft ontwerpers en ontwikkelaars wel een gedeelde terminologie. In plaats van ontwerpbeslissingen telkens opnieuw te vertalen wanneer werk wordt overgedragen, kunnen beide kanten met dezelfde benoemde waarden en relaties werken.

Bouw een tokenstructuur die zowel ontwerpers als ontwikkelaars begrijpen

De betrouwbaarste tokenstructuren bestaan meestal uit meer dan één niveau. Primitieve tokens slaan basiswaarden op, zoals colour/blue/500, spacing/16 of radius/8. Semantische tokens leggen het doel van deze waarden uit, met namen zoals colour/text/primary, colour/background/surface of spacing/component/medium. Componentspecifieke tokens kunnen worden toegevoegd wanneer een component daadwerkelijk een eigen gecontroleerde beslissing nodig heeft, zoals button/background/primary/default. Deze structuur voorkomt dat het designsysteem verandert in een lijst met honderden losstaande waarden. Belangrijker nog is dat visuele wijzigingen zich voorspelbaar door het systeem kunnen verplaatsen: een primitieve waarde kan veranderen terwijl semantische en componentspecifieke verwijzingen intact blijven.

Naamgeving is daarom belangrijker dan aanvankelijk misschien lijkt. Namen die uitsluitend op uiterlijk zijn gebaseerd, verouderen doorgaans slecht. Een token met de naam blue-button kan misleidend worden wanneer de knop na een rebranding groen wordt, terwijl action-primary correct kan blijven. Hetzelfde principe geldt voor afstanden en typografie. Namen moeten waar mogelijk het doel beschrijven en in Figma en code dezelfde conventie volgen. Wanneer Figma colour/background/primary gebruikt terwijl de codebase dezelfde waarde mainBlueBackground noemt, moeten ontwikkelaars ondanks synchronisatie nog steeds begrippen handmatig vertalen. Het vastleggen van deze terminologie voordat honderden variabelen worden aangemaakt, is doorgaans goedkoper dan later een volledig gevestigd systeem te moeten hernoemen.

Modes moeten eveneens echte variaties vertegenwoordigen en niet dienen als opslagplaats voor willekeurige alternatieven. Een lichte en een donkere mode kunnen verschillende waarden bevatten voor dezelfde semantische achtergrond- of tekstvariabele, omdat de betekenis gelijk blijft terwijl de context verandert. Figma kan JSON-bestanden in DTCG-formaat als modes importeren en wanneer meerdere bestanden in een nieuwe collectie worden geïmporteerd, kan elk geschikt bestand een afzonderlijke mode creëren. Teams moeten tijdens dit proces goed letten op de naamgeving, omdat Figma geneste tokennamen normaliseert met schuine strepen en conflicterende namen ertoe kunnen leiden dat dubbele tokens tijdens het importeren worden overgeslagen. Een kort naamgevingsbeleid voor hiërarchie, hoofdlettergebruik, afkortingen en verouderde tokens voorkomt veel vermijdbare problemen.

Een gecontroleerde workflow voor synchronisatie van Figma naar code opzetten

De eerste operationele beslissing is bepalen waar goedgekeurde wijzigingen aan tokens ontstaan. Sommige teams geven de voorkeur aan een code-first-model waarin JSON-tokenbestanden samen met de codebase de gezaghebbende bron vormen en goedgekeurde wijzigingen in Figma worden geïmporteerd. Andere teams laten beheerders van het designsysteem variabelen in Figma definiëren en exporteren of synchroniseren die daarna naar de ontwikkelrepository. Beide modellen kunnen werken. Problemen ontstaan wanneer Figma en code als afzonderlijke gezaghebbende bronnen worden behandeld en mensen hetzelfde token aan beide kanten mogen aanpassen zonder een proces om verschillen te verzoenen. Een duidelijke eigenaar en een vastgelegde richting voor wijzigingen zijn waardevoller dan een uitgebreide toolchain met onduidelijke verantwoordelijkheden.

Voor veel teams begint een praktische workflow in 2026 met DTCG-compatibele tokenbestanden onder versiebeheer. Een voorgestelde wijziging krijgt dezelfde beoordelingsdiscipline als andere gedeelde productonderdelen: de auteur past een token aan, het verschil is zichtbaar in de wijzigingsgeschiedenis, reviewers beoordelen het effect en de goedgekeurde versie wordt gebruikt om de benodigde uitvoer bij te werken. Met de native tokenimport van Figma kunnen vervolgens overeenkomende variabelen en modes worden bijgewerkt zonder dat een ontwerper iedere waarde handmatig hoeft te veranderen. Wanneer Figma de bron voor wijzigingen is, kunnen geëxporteerde tokengegevens in de tegenovergestelde richting worden verwerkt. Versiebeheer vormt daarbij een belangrijk vangnet, omdat het team exact kan zien wat er is gewijzigd en een eerdere toestand kan herstellen wanneer een update een ongewenst resultaat veroorzaakt.

Grotere organisaties kunnen een groter deel van dit proces automatiseren met de Variables REST API van Figma. Deze API ondersteunt het lezen, aanmaken, bijwerken en verwijderen van variabelen en wordt specifiek beschreven voor workflows die Figma koppelen aan continuous integration-systemen of een centrale bron voor het designsysteem. Toegang tot de Variables REST API is momenteel onderworpen aan de Enterprise-vereisten van Figma en moet daarom niet als universele oplossing voor ieder team worden gepresenteerd. Kleinere organisaties kunnen nog steeds een bruikbaar proces opbouwen rond native import en export, goedgekeurde tokenbestanden en geschikte plugins. Het belangrijkste is dat routinematige overdracht van waarden via een herhaalbaar proces verloopt in plaats van afhankelijk te zijn van iemand die eraan moet denken een nieuwe kleur- of afstandswaarde naar meerdere afzonderlijke locaties te kopiëren.

Zet gedeelde tokens om in productiewaarden in plaats van ze handmatig te kopiëren

Zodra er een goedgekeurd tokenbestand bestaat, heeft de ontwikkelzijde een herhaalbare manier nodig om het om te zetten in waarden die de applicatie kan gebruiken. Tools zoals Style Dictionary worden hiervoor vaak gebruikt, omdat ze een centrale tokenverzameling kunnen omzetten naar uitvoer die geschikt is voor CSS, JavaScript, iOS, Android en andere ontwikkeldoelen. Style Dictionary ondersteunt de DTCG-aanpak, al moeten teams die nieuwere of meer gespecialiseerde onderdelen van de specificatie 2025.10 gebruiken de actuele compatibiliteitsinformatie controleren voordat zij daarvan afhankelijk worden. Voor een standaard systeem met kleuren, afstanden en typografie blijft het principe eenvoudig: beheer de beslissing één keer en genereer de representaties die elk product nodig heeft, in plaats van parallelle lijsten handmatig bij te houden.

Denk bijvoorbeeld aan een wijziging van een semantisch token met de naam colour/background/brand. In een niet-gesynchroniseerde workflow verandert een ontwerper de kleur in Figma, stuurt een bericht naar een ontwikkelaar, zoekt de ontwikkelaar naar de bijbehorende CSS-waarde, werkt een andere ontwikkelaar de mobiele applicatie bij en ontdekt iemand later dat een hoverstatus nog steeds de oude kleur gebruikt. Met gedeelde tokens verandert de goedgekeurde waarde bij de bron, blijven verwijzingen naar dezelfde semantische naam wijzen en ontvangt de gegenereerde code de bijgewerkte waarde tijdens het normale buildproces. Beoordeling blijft nodig, vooral voor toegankelijkheid en onverwachte visuele gevolgen, maar de herhaaldelijke overdracht van dezelfde waarde verdwijnt.

Figma Dev Mode helpt deze verbinding tijdens de overdracht in stand te houden. Ontwikkelaars die een variabele inspecteren, kunnen de naam, collectie, actieve mode, opgeloste waarde en aliasstructuur zien in plaats van alleen de uiteindelijke ruwe waarde te ontvangen. Figma maakt het daarnaast mogelijk om codesyntaxis aan variabelen te koppelen, waarbij de huidige snippets CSS, SwiftUI en Compose ondersteunen. Een ontwikkelaar kan daardoor zien dat een element een afgesproken variabele uit het designsysteem gebruikt in plaats van iedere geïnspecteerde waarde als een afzonderlijke instructie te behandelen. Dat is vooral nuttig tijdens code reviews: een hardgecodeerde kleur zoals #1F2937 kan ter discussie worden gesteld wanneer het component eigenlijk het vastgelegde teksttoken hoort te gebruiken, waardoor afwijkingen makkelijker kunnen worden opgespoord voordat ze onderdeel worden van de gepubliceerde interface.

Handmatige correcties voorkomen vereist zowel beheer als automatisering

Synchronisatie van tokens mislukt wanneer teams zich alleen richten op het exporteren van waarden en negeren hoe die waarden worden aangemaakt en gewijzigd. Niet iedere meting in een Figma-bestand hoeft een token te worden. Wanneer ontwerpers voor iedere iets andere marge, kleur of hoekafronding een nieuwe variabele maken, wordt de tokenbibliotheek al snel moeilijker te begrijpen dan de ruwe waarden die zij moest vervangen. Een nuttige vraag is of een beslissing wordt herhaald, betekenisvol is of naar verwachting als onderdeel van het systeem zal veranderen. Een terugkerende oppervlaktekleur verdient een token; een eenmalige coördinaat in een illustratie waarschijnlijk niet. Door de collectie doelgericht te houden, wordt het voor ontwerpers eenvoudiger de juiste variabele te kiezen en voor ontwikkelaars makkelijker om de gegenereerde uitvoer te vertrouwen.

Wijzigingen hebben ook duidelijk eigenaarschap nodig. Een volwassen workflow bepaalt wie een nieuw token mag toevoegen, wie wijzigingen aan bestaande semantische waarden goedkeurt en wat er gebeurt wanneer een token niet langer nodig is. Het hernoemen of verwijderen van een bestaand token kan veel componenten beïnvloeden, zelfs wanneer de visuele waarde zelf niet verandert. Uitfaseren is meestal veiliger dan onmiddellijk verwijderen: markeer het oude token als verouderd, geef de vervanger aan, migreer de afhankelijke onderdelen en verwijder het token pas nadat het gebruik is gecontroleerd. Wijzigingsregistraties moeten het doel van belangrijke aanpassingen toelichten en niet simpelweg vermelden dat een waarde van de ene hexadecimale code naar de andere is veranderd. Zo krijgen zowel ontwerp- als ontwikkelteams voldoende context om te beoordelen of een wijziging bewust is doorgevoerd.

Geautomatiseerde controles kunnen voorspelbare fouten afvangen voordat de visuele beoordeling begint. Een tokenbestand kan worden gecontroleerd op ongeldige syntaxis, dubbele namen, ontbrekende verwijzingen, inconsistente typen of onverwachte hardgecodeerde waarden. Visuele en toegankelijkheidscontroles moeten vervolgens de effecten beoordelen die tokenvalidatie niet zelfstandig kan beoordelen. Een wijziging aan een tekst- of achtergrondtoken kan bijvoorbeeld het kleurcontrast van veel componenten tegelijk veranderen. Een succesvolle build bewijst daarom niet dat een ontwerpwijziging geschikt is. Automatisering moet repetitieve controlewerkzaamheden wegnemen, zodat mensen hun beoordelingstijd kunnen besteden aan bruikbaarheid, hiërarchie, toegankelijkheid en productcontext in plaats van lijsten met kleurcodes te vergelijken.

Een praktisch invoeringsplan voor bestaande designsystemen in 2026

Een bestaand product hoeft niet iedere ontwerpbeslissing in één keer om te zetten naar tokens. Een veiligere eerste stap is een inventarisatie van de waarden die al herhaaldelijk voorkomen in Figma en productie. Kleuren zijn vaak het eenvoudigste vertrekpunt, omdat inconsistenties zichtbaar zijn en semantische rollen zoals tekst, oppervlak, rand, actie en status meestal goed kunnen worden vastgesteld. Afstanden, hoekafrondingen en typografie kunnen volgen zodra het team de naamgevingsregels heeft getest. Tijdens de inventarisatie moeten herhaalde hardgecodeerde waarden worden gekoppeld aan voorgestelde primitieve en semantische tokens. Waarden die op elkaar lijken maar verschillende functies hebben, moeten niet automatisch worden samengevoegd alleen omdat hun huidige numerieke waarden toevallig gelijk zijn.

De volgende stap is een beperkte productietest. Eén componentfamilie of één duidelijk afgebakend deel van de interface kan de nieuwe tokens van ontwerp tot gepubliceerde code gebruiken. Het team kan vervolgens praktische vragen controleren die moeilijk vanuit een theoretische specificatie te beantwoorden zijn: begrijpen ontwerpers de namen, kunnen ontwikkelaars de juiste tokens in Dev Mode vinden, worden dark-modewaarden correct opgelost, produceert het codegeneratieproces leesbare namen en kan een oud token worden vervangen zonder verborgen problemen te veroorzaken? Zodra deze vragen duidelijke antwoorden hebben, kan dezelfde workflow naar aanvullende componenten worden uitgebreid. Deze stapsgewijze aanpak maakt het ook eenvoudiger om verouderde lokale stijlen te verwijderen in plaats van twee systemen onbeperkt naast elkaar te blijven onderhouden.

Succes moet worden gemeten aan de hoeveelheid afwijkingen die de workflow wegneemt, niet aan het aantal aangemaakte tokens. Bruikbare indicatoren zijn onder meer minder hardgecodeerde designsysteemwaarden in productie, minder verschillen tussen Figma en gepubliceerde componenten, een kortere tijd tussen een goedgekeurde tokenwijziging en de implementatie ervan en minder handmatige correcties tijdens ontwerpbeoordelingen. Figma verkleinde in 2026 zelf verder de afstand tussen ontwerp en code: een update in juli bracht het gedrag van auto layout dichter bij CSS, terwijl een andere update in juli het mogelijk maakte om bij codegebaseerde schermen op het canvas kleuren, typografie en afstanden te koppelen aan veel variabelen die al in het bestand aanwezig zijn. Deze verbeteringen bevestigen de richting waarin de werkwijze zich ontwikkelt, maar een betrouwbaar tokensysteem blijft afhankelijk van duidelijke naamgeving, eigenaarschap, gecontroleerde wijzigingen en geautomatiseerde validatie. Wanneer die basis op orde is, kunnen Figma en productie ontwerpbeslissingen delen in plaats van ze steeds opnieuw op te bouwen.