Every design system has the same problem: a designer updates a colour in Figma, someone manually updates the CSS, someone else notices the button component didn’t get the memo, and three weeks later a PM files a bug that says “the blue is wrong.” The gap between what a designer intends and what ships to production is where design systems quietly fall apart.
The fix isn’t more process or more Slack reminders. It’s a pipeline — an automated flow from Figma variables through a token transformation layer into production CSS and TypeScript, validated by visual testing in CI. Once it’s built, design-engineering drift becomes nearly impossible.
“Automation is not about replacing people. It’s about amplifying their intent.” — Jina Anne
The Design-Engineering Drift Problem
Design-engineering drift is what happens when Figma and code have no shared source of truth. Everything is manually synchronized, which means everything eventually diverges.
| Symptom | Root Cause |
|---|
| Colours in Figma don’t match production | Manual handoff with no single source of truth |
| Spacing is “close but not quite” | Designers and engineers eyeball values independently |
| Dark mode has inconsistencies | Token mappings between themes aren’t automated |
| Rebrands take months instead of days | Tokens are scattered across dozens of stylesheets |
| ”It looks different on staging” | No visual regression testing in the CI pipeline |
The underlying issue is always the same: two sources of truth that are manually kept in sync. Manual sync is a polite way of saying “they’ll drift, and nobody will notice until a customer complains.”
Don’t build this pipeline until your design system has real adoption. If nobody uses the components, automating the tokens is optimising the wrong thing. Fix adoption first — then automate the plumbing.
The Pipeline Stages
The token pipeline has four stages, each building on the previous one. Think of it as a supply chain from design intent to production pixels.
| Stage | Input | Output | Who Owns It | Key Tool |
|---|
| 1. Source of Truth | Design decisions (colours, spacing, typography, radii) | Figma Variables organized in primitive → semantic → component layers | Designers | Figma Variables |
| 2. Token Export | Figma Variables API response | Structured JSON files in Style Dictionary format | Automated (CI) | GitHub Action + Figma API |
| 3. Transformation | Raw token JSON | Platform-specific outputs — CSS custom properties, TypeScript constants, mobile values | Automated (CI) | Style Dictionary |
| 4. Consumption + Validation | CSS/TS token files | Components using tokens, validated by visual regression testing on every PR | Engineers + CI | Chromatic / Playwright |
The layering within Figma Variables matters enormously. Primitive tokens are raw values (blue-500: #3B82F6). Semantic tokens are contextual mappings (color-primary: {blue-500}). Component tokens are specific (button-bg: {color-primary}). This layering is what makes a rebrand possible in hours instead of months — you change 12 primitive tokens and the entire UI updates.
Start with semantic tokens, not primitives. Engineers should never reference blue-500 in code — they should reference color-primary. This indirection is what makes rebrands, white-labelling, and theme switching possible without touching component code.
Figma Variables to Style Dictionary to CSS/TS
The middle of the pipeline is where the magic happens. Here’s how the three layers connect conceptually.
Step 1: Figma Variables as the source of truth. All design decisions live in Figma’s native variables system. Designers work there. The API exposes them programmatically.
Step 2: A scheduled CI job fetches tokens. A GitHub Action runs daily (and on-demand) to call the Figma Variables API, transform the response into Style Dictionary’s JSON input format, and open a PR if anything changed. This is the bridge between design and engineering — automated, auditable, and version-controlled.
Step 3: Style Dictionary transforms tokens. It takes the raw JSON and generates platform-specific outputs. One config file produces CSS custom properties for the web, TypeScript constants for type-safe access, and could produce Swift/Kotlin values for mobile.
// style-dictionary.config.js — one config, multiple platform outputs
module.exports = {
source: ['tokens/**/*.json'],
platforms: {
css: {
transformGroup: 'css',
buildPath: 'packages/tokens/css/',
files: [{ destination: 'variables.css', format: 'css/variables' }],
},
typescript: {
transformGroup: 'js',
buildPath: 'packages/tokens/ts/',
files: [{ destination: 'tokens.ts', format: 'javascript/es6' }],
},
},
};
The output is clean, predictable, and version-controlled. CSS gets :root variables. TypeScript gets typed constants. Dark mode gets a [data-theme="dark"] override block generated from the same source tokens. No manual mapping. No drift.
Dark Mode and Theme Tokens
The real power of the pipeline shows with dark mode. Instead of maintaining separate stylesheets, the semantic token layer handles everything through variable reassignment.
| Semantic Token | Light Value | Dark Value |
|---|
color-bg-primary | white | gray-900 |
color-text-primary | gray-900 | gray-50 |
color-border-default | gray-200 | gray-700 |
color-surface-raised | white | gray-800 |
When the data-theme attribute changes on the root element, every component updates automatically. Zero component-level dark mode logic. Zero conditional class names for themes. The indirection that seemed unnecessary when you had one theme becomes essential the moment you have two.
Results Metrics
The pipeline is an investment. Here’s what the return looks like.
| Metric | Before Pipeline | After Pipeline |
|---|
| Token sync time | 1–2 weeks (manual, error-prone) | Same day (automated, auditable) |
| Dark mode bugs per quarter | ~12–15 | ~2–3 |
| Rebrand effort | Estimated 6–8 weeks | 1–2 days |
| Visual regressions caught in CI | 0 (caught by users) | ~10–15 per month (caught before merge) |
| Design-engineering alignment meetings | Weekly, 1 hour | Bi-weekly, 30 minutes |
The alignment meeting reduction is an underrated win. When the pipeline ensures tokens are always in sync, the meetings shift from “why does this look wrong” to “what should we build next.” That’s a cultural shift as much as a technical one.
The Cultural Shift
The hardest part of this pipeline isn’t technical — it’s cultural. Three groups of people need to change how they work.
| Role | Old Habit | New Discipline |
|---|
| Designers | One-off hex codes in Figma, styles not connected to variables | Everything goes through the variable system — no exceptions |
| Engineers | ”I’ll just hardcode this colour for now” | Trust the pipeline. Use tokens. If a token doesn’t exist, request it. |
| Product managers | Push for speed over process | Accept the upfront investment. The payoff is a rebrand in days, not months. |
The Figma Variables API is still evolving, and complex token relationships (like responsive spacing scales) require custom Style Dictionary transforms. Even at 80% automation, the time savings are massive compared to manual synchronisation. Perfect is the enemy of shipped.
Design tokens aren’t glamorous. Nobody tweets about them. But they’re the plumbing that makes a design system actually work — and plumbing that works is the best kind.