Figma Variables landade 2023 som plattformens länge efterlängtade svar på design tokens. Funktionen är kraftfull: namngivna samlingar av primitiva värden — färger, nummer, strängar, booleaner — som du kan binda till vilken egenskap som helst i vilken komponent som helst. Ändra variabeln, varje instans uppdateras. Lägg till en mörkt läge-samling, varje variabelbindning byts automatiskt.
För AI-kodgenerering är Variables inte bara användbara. De är mekanismen som omvandlar en Figma-fil från en pixelperfekt mockup till en spec din agent kan implementera korrekt. När en färg har ett namn — color/brand/primary, inte #7F5CFE — kan agenten mappa den till en kod-token, implementera mörkt läge korrekt och producera utdata som deltar i ditt faktiska designsystem.
Här är problemet: de flesta Figma-filer i aktiv användning idag har inte Variables inställda. figmascope hanterar båda fallen. Det här inlägget förklarar hur.
Vad Variables faktiskt är
En Figma Variable är ett namngivet skalärt värde bundet till en samling. Samlingar organiserar variabler efter läge — "Light" och "Dark" är det kanoniska exemplet. Varje variabel i en samling kan ha olika värden per läge: color/surface/background är #FFFFFF i Light och #0D0D0D i Dark. Bindningen fortplantas: varje fyllning som refererar till color/surface/background uppdateras när du byter läge.
Variables kan vara färger, nummer, strängar eller booleaner. I praktiken är de mest impaktfulla färger och nummer — vilket täcker det mesta av token-ytan i ett typiskt designsystem: färgpalett, avståndsskala, kantradier, teckenstorlekar, elevationsvärden.
Figma exponerar Variables via sitt REST API som en localVariables-samling. Varje variabel har ett ID, ett namn, en typ och värden per läge. Komponentegenskaper som refererar till variabler bär ett boundVariables-fält med variabel-ID:t. Det här är strukturerad data som reser smidigt genom extraheringspipelinen.
Den lyckliga vägen: Variables finns
När en Figma-fil har Variables läser figmascope dem från API:et och bygger en tokens.json som följer en W3C Design Tokens Community Group-kompatibel struktur. Varje token har ett $value och en $type. Färgtokens får hexvärden med valfri alfa. Avståndstokens får numeriska värden med ett px-enhetstips. Tokennamnet följer variabelns samlings- och namnsökväg:
{
"color": {
"brand": {
"primary": { "$value": "#7F5CFE", "$type": "color" }
},
"surface": {
"background": { "$value": "#FFFFFF", "$type": "color" }
}
},
"spacing": {
"4": { "$value": 4, "$type": "number" },
"8": { "$value": 8, "$type": "number" },
"16": { "$value": 16, "$type": "number" }
}
}När per-skärm IR byggs får varje fyllning som hade en boundVariables-referens tokennamnet istället för det lösta hex-värdet. Noden bär:
"fills": [{ "type": "SOLID", "tokenRef": "color/brand/primary" }]Inte #7F5CFE. Tokennamnet. Agenten läser detta och genererar background-color: var(--color-brand-primary) eller Color.brandPrimary eller vilket konsumtionsmönster för tokens som målramverket använder. Det är den utdata du vill ha: kod som är kopplad till ditt designsystem, inte kod som går sönder i det ögonblick en designer uppdaterar en färg.
Semantisk namngivning är skillnaden mellan kod som åldras väl och kod som driftar. Ett hexvärde i källkoden är en skuld; en tokenreferens är ett kontrakt. Variables är vad som gör Figma-filer kapabla att uttrycka kontrakt, inte bara pixlar.
Verkligheten: de flesta filer har inte Variables
Variables kräver Figma Professional-plan eller högre. De kräver en designer som har ställt in dem — vilket innebär att skapa samlingar, namnge variabler och manuellt binda dem till varje komponentegenskap. I en mogen, välunderhållen designsystemfil är detta gjort. I ett startups produkt-Figma, en frilansares kundfil, eller en fil som föregår Variables-funktionen, är det det typiskt inte.
figmascope var designat för att vara användbart för de filerna också. Det degraderar elegant: när Variables saknas faller det tillbaka på frekvensbaserad tokeninferens.
Fallback: härledd från frekvens
Inferensalgoritmen fungerar så här:
- Gå igenom varje bladnod i varje exporterad ram.
- Samla alla fyllningsfärger, avståndsvärden och kantradier.
- Räkna förekomster av varje unikt värde.
- Värden som förekommer över ett frekvenströskel befordras till härledda tokens.
- Varje token får ett värdebaserat namn:
color.7f5cfe,spacing.16,radius.8.
Utdatan tokens.json ser strukturmässigt liknande ut som Variables-vägen, men namnen är värdebaserade snarare än semantiska:
{
"color": {
"7f5cfe": { "$value": "#7F5CFE", "$type": "color" },
"f6f2ea": { "$value": "#F6F2EA", "$type": "color" }
},
"spacing": {
"16": { "$value": 16, "$type": "number" },
"8": { "$value": 8, "$type": "number" }
}
}I IR får noder som använder dessa värden tokenreferenser: "tokenRef": "color.7f5cfe". Inte hårdkodade literaler. Referenser — bara till härledda tokens snarare än namngivna.
Agenten genererar fortfarande token-refererad kod. var(--color-7f5cfe) är inte lika läsbart som var(--color-brand-primary), men det är fortfarande en token — du kan söka-och-ersätta den, du kan döpa om den, du kan granska dess användning. Det är ett namngivet handtag på ett värde, inte ett magiskt tal.
Fältet tokensSource
Varje figmascope-paket inkluderar en _meta.json som dokumenterar vad som finns i paketet och hur det producerades. Fältet tokensSource har tre möjliga värden:
figma-variables— Variables fanns och användes. Tokennamn är semantiska.inferred-from-frequency— Inga Variables hittades. Tokens härleddes från värdefrekvens. Namn är värdebaserade.none— Inga tokens kunde extraheras eller härledas. IR använder lösta värden direkt.
Det här spelar roll för att det berättar för den konsumerande agenten (och för utvecklaren som läser paketet) exakt hur mycket de kan lita på tokennamnen. Ett figma-variables-paket är sanningskälla för ditt designsystem. Ett inferred-from-frequency-paket är ett användbart strukturellt ställverk som behöver designergranskning av namn innan det är kanoniskt. Ett none-paket är en startpunkt med hårdkodade värden som behöver tokeniseras senare.
Ärliga metadata är undervärderade. Verktyg som tyst härleder utan att flagga det som inferens skapar falsk tilltro. figmascope visar inferenskedjan explicit så att du vet vad du arbetar med.
Varför frekvensbaserad inferens är bättre än ingenting
Alternativet till frekvensbaserad inferens är att mata ut lösta literalvärden överallt — #7F5CFE i varje fyllningsnod som använder den färgen. Det producerar kod som är svårare att refaktorera, svårare att granska och svårare att koppla till ett designsystem när ett sådant eventuellt läggs till.
Frekvensbaserad inferens extraherar åtminstone den uppsättning värden som designen faktiskt använder. Om #7F5CFE förekommer 47 gånger i designen är det ett signal: det är en primärfärg, inte en accentfärg. Tokennamnet vet inte det — det är bara color.7f5cfe — men frekvensdata berättar historien. En agent som fått de härledda tokens kan göra rimliga gissningar om vilka värden som är primära och vilka som är engångsförekomster.
Mer praktiskt: frekvensbaserad inferens ger dig en tokens.json som är diffbar över versioner. Om du exporterar samma fil två gånger efter att en designer ändrade en återkommande färg visar diffen att tokenvärdet ändrades. Utan inferens skulle du jaga varje enskild literaländring utspridd över flera IR-filer.
Vad designers fortfarande bör göra
Frekvensbaserad inferens är ett kompatibilitetslager, inte en ersättning för Variables. Den rätta vägen är för designers att anta Variables för alla värden som deltar i ett designsystem: varumärkesfärger, neutral skala, avståndsskala, kantradier, elevation, typografi. När dessa väl finns på plats går figmascope-paketet från ställverks-tokens till produktionskvalitets-tokens.
Variables låser också upp tematisering i paketet: flera lägesvärden per token. En fil med Light/Dark-lägen producerar en tokens.json med per-läge-värden som matar direkt in i CSS custom properties med media query-åsidosättanden, eller plattformsspecifika temobjekt. Det här är omöjligt att härleda från en enda designögonblicksbild — det kräver explicit designeravsikt, uttryckt genom Variables.
Uppgraderingsvägen är inkrementell. Ett team kan börja med inferenskvalitets-tokens idag, anta Variables gradvis allteftersom designsystemet mognar och automatiskt få bättre paket när de gör det. Fältet tokensSource spårar var du befinner dig i den progressionen.
Tokenpipelinen i sin helhet
För att göra det konkret, här är den fullständiga upplösningsordningen figmascope använder för varje fyllning i IR:
- Har noden en
boundVariables.fills-referens? Om ja, lös till variabelnamnet och läge-noll-värdet. Tokenkälla:figma-variables. - Finns det lösta värdet i de frekvensbaserat härledda tokens (över tröskeln)? Om ja, mappa till det härledda tokennamnet. Tokenkälla:
inferred-from-frequency. - Annars: använd det lösta hexvärdet direkt. Ingen tokenreferens. Tokenkälla:
none.
Stegen provas i ordning. Den högst kvalitativa källan vinner. Fältet tokensSource i _meta.json återspeglar den dominerande vägen för paketet som helhet.
Det innebär att en delvis Variables-satt fil — där vissa komponenter har bindningar och andra inte — producerar ett blandat paket. Namngivna tokens där de finns, härledda tokens där de inte finns. Det är rätt beteende: använd varje skrap strukturerad information som finns tillgänglig, falla tillbaka elegant där den saknas och var ärlig om vilken väg varje värde tog.
Exportera ditt paket från figmascope-appen för att se vilken tokensSource din fil producerar. Använd sedan paketet med Claude Code eller Cursor för korrekt, token-refererad kodgenerering.