The historical problem: Figma and code, two worlds that drift
For ten years, the same scenario has played out in most product teams. Designers maintain a carefully structured Figma file: palettes, typographies, spacing, component states. Developers maintain, in parallel, a tailwind.config.js file or a set of CSS variables. The two files look alike. The two files drift.
The symptom is well known. The primary blue in Figma (#2563EB) is not the --color-blue-500 in Tailwind (#3B82F6). The gap looks harmless in a meeting, but it accumulates: on every new feature, a designer mocks up with the Figma version, a developer implements with the code version, and nobody notices the two screens are not identical. After six months, the design system has become a suggestion.
The consequences are concrete: design review time explodes, Slack back-and-forth to validate every colour, visual debt settling in, and above all, loss of trust between the two teams. Designers end up dreading production deployments. Developers end up ignoring the Figma file. It is the classic stillborn-design-system syndrome.
The root cause is not a lack of discipline. It is the absence of a single source of truth and an automated pipeline. In 2026, with the maturity of Figma Variables, the emergence of the W3C Design Tokens format, and Tailwind v4's CSS-native integration, that pipeline is finally within reach. This article describes how to build it.
Figma Variables (2024): the typed foundation of the modern pipeline
Figma generalised Variables in 2024, and it is the change that makes the modern pipeline possible. For the first time, Figma has true typed variables: colour, number, string, boolean. A far cry from simple styles that only carried a visual value.
The model is solid. Variables are organised into Collections (for example Primitives, Semantic, Components), each collection exposes Modes (light, dark, density-compact, density-comfortable), and variables support aliases. A semantic variable --color-bg-primary can reference --color-neutral-0 in light mode and --color-neutral-950 in dark mode. The mode becomes a reference switch, not a duplication.
This structure mirrors exactly the hierarchy expected on the code side: raw tokens (palette, spacing scale, durations), semantic tokens (background, border, and accent colours per context), component tokens (the button's primary variant). The two trees, Figma and code, can finally be isomorphic — which is the sine qua non condition for automatic synchronisation.
On our recent projects, we always start from a Figma file structured in three distinct collections. Designers work only on the semantic and component layers; primitives are modified only at the start of a brand cycle. This discipline simplifies design review and sets the stage for automatic export.
Tokens Studio: the bridge from Figma to the W3C format
Tokens Studio (formerly Figma Tokens) is the plugin that bridges Figma Variables and code. It syncs Figma variables to a GitHub repo in JSON format, and opens a pull request on every change. It is the link that turns a design decision into a reviewable code diff.
The export format aligns with the W3C Design Tokens Format Module, the emerging standard carried by the community (Adobe, Amazon, Microsoft, Token Studio, Knapsack). The draft specifies the expected structure: $type, $value, descriptions, extensions, groups, aliases. Adopting this format is not a cosmetic choice; it is aligning with the vocabulary every tool in the sector will adopt in the coming years.
Concretely, a colour token looks like { "$type": "color", "$value": "#2563EB" }. An alias becomes { "$value": "{color.blue.600}" }. Modes (light, dark) are serialised into distinct collections. This JSON is readable, diffable, versionable: exactly what a healthy code review needs.
The great advantage of Tokens Studio is bidirectional sync. A developer who fixes a token directly in the JSON (for example to align a WCAG contrast) sees the correction flow back to Figma. No more silent divergence. The PR becomes the single place for design-dev discussion, with screenshots, comments, and history.
Style Dictionary: one source of truth, N outputs
Style Dictionary, maintained by Amazon, is the transformation engine. It takes a folder of JSON tokens as input and generates as many outputs as needed: CSS variables, TypeScript constants, Swift enums, Kotlin resources, Android XML, SCSS, LESS. It is the tool that makes a multi-platform pipeline realistic.
The principle is simple and robust. You declare transformers (change a kebab-case name to camelCase, convert a hex to RGB, generate an opaque variant), output formats (a CSS template that produces :root { --color-bg-primary: #fff; }), and destinations (apps/web/styles/globals.css, apps/mobile/src/theme/tokens.ts, apps/docs/storybook/tokens.json). A single command (style-dictionary build) regenerates everything from the source JSON.
On a typical multi-platform project, the source lives in a dedicated design-tokens repo. Consuming applications (web, mobile, docs) never commit tokens manually: they are regenerated by CI on every merge. It is the strict application of the one source of truth, N outputs principle. Any inconsistency between platforms becomes structurally impossible.
Style Dictionary's strength is its customisability. For Tailwind v4, we write a custom format that directly produces an @theme block. For Storybook, a JSON format adapted to the Design Tokens addon. For tests, a typed TypeScript format exposing { color: { bg: { primary: "var(--color-bg-primary)" } } }, convenient for assertions in component tests.
CI pipeline: Figma to GitHub, Style Dictionary, multi-repo PRs
The productionised workflow looks like this. A designer modifies a variable in Figma. Tokens Studio pushes the updated JSON to the design-tokens repo on the feat/update-primary-blue branch. A GitHub Action triggers, runs style-dictionary build, then opens PRs to the consumer repos: apps/web (CSS), apps/mobile (TS), docs/storybook (JSON).
Each PR contains the diff of the generated files and a summary of the modified tokens. Reviews happen as a team: a designer validates visual coherence, a developer validates technical impact (rename, removal, addition). GitHub Actions workflows can block the merge if a test fails — for example a Chromatic visual-regression test or a Playwright snapshot.
Automatic validation is non-negotiable. On every PR, the CI runs: WCAG contrast checks (Pa11y, axe-core), alias coherence verification (no circular references), JSON schema validation against the W3C format. If a colour token does not pass the 4.5:1 threshold on a given background, the PR is blocked with an explicit message. The team does not discover the problem in production — the pipeline catches it.
On a mature workflow, you add an auto-merge step for non-breaking cosmetic changes (adding a token, fixing contrast without a rename). Breaking changes (rename, removal) require explicit human review. This segmentation reduces review fatigue while preserving safety. The observed ratio: 70% of PRs auto-merged, 30% in manual review.
Tailwind v4 @theme: tokens as native CSS citizens
Tailwind v4 changed the game by pushing tokens to native CSS via the @theme directive. Gone is the verbose tailwind.config.js that duplicated variables in JavaScript. Tokens now live in globals.css as real custom properties, and Tailwind consumes them to generate utilities.
Style Dictionary therefore produces an @theme block directly. The output looks like @theme { --color-bg-primary: #ffffff; --color-fg-primary: #0a0a0a; --color-accent: #2563EB; --radius-md: 0.5rem; }. Tailwind v4 automatically exposes the utilities bg-bg-primary, text-fg-primary, bg-accent, rounded-md. No intermediate layer, no manual mapping.
The major benefit is dark mode. In v3, you had to add dark: on every class, which multiplied variants and weighed down the code. In v4 with @theme, dark mode becomes a simple variable switch: you redefine the semantic tokens in a [data-theme="dark"] selector or @media (prefers-color-scheme: dark), and the whole design system flips automatically. Component code does not change. One line of CSS is enough.
On the VALRY LABS codebase, this change cut the final CSS from 32 kB to 18 kB gzip (-44%), while radically simplifying dark-mode maintenance. Tokens generated by the Figma pipeline then Style Dictionary are now consumed natively, with no intermediate JavaScript layer. The pipeline gains in coherence and performance.
A11y: contrast checks mandatory in the pipeline
Every colour token in the pipeline must pass WCAG AA: a contrast ratio of 4.5:1 for normal text, 3:1 for large text (at least 24 px regular or 18.66 px bold) and for interface components. This is not a manual check at the end of a project; it is an automated test that runs on every token PR.
Concretely, the CI runs Pa11y or axe-core on a demonstration page that uses all the semantic tokens in their canonical contexts (text on background, icon on background, border on background). For each combination, the ratio is computed. If a pair does not pass the threshold, the PR is blocked. It is the equivalent of a unit test, but for readability.
For at-risk combinations (a light accent on a light background, for example), the pipeline automatically generates alternative tokens. If --color-accent does not pass on --color-bg-primary, the system proposes --color-accent-on-primary, a darker variant computed to respect the threshold. The designer does not have to derive the variant manually: the pipeline suggests it, and the designer validates.
Beyond contrast, the pipeline also validates the coherence of states (hover, focus, active, disabled): every state must retain sufficient contrast. Focus-ring tokens must be visible on every possible background. This automatic discipline turns accessibility into an emergent property of the system rather than an additional burden. It is the condition for sustainably delivering a Lighthouse a11y score of 95 or higher.