Syncing design tokens from Figma to code

WHAT THIS TESTS This checks whether you can design a pipeline where tokens have a single source of truth and propagate automatically, instead of being hand-copied between design and code.

A GOOD ANSWER COVERS Decide the source of truth. Commonly Figma Variables hold the primitives and semantic aliases. Export them via a plugin like Tokens Studio or the Figma Variables API into a standard, tool-agnostic format, ideally the DTCG design-tokens JSON, and commit that file to the repo so it is versioned and reviewable. Run a transformation step, typically Style Dictionary, to generate platform-specific outputs from the one JSON: CSS custom properties and a Sass map for web, a typed TS object for the component library, and native formats if you ship iOS or Android. Wire it into CI: a scheduled or webhook-triggered job pulls the latest tokens, regenerates outputs, and opens a PR so humans review the diff before it merges. This keeps three-tier tokens (primitive, semantic, component) consistent and makes every change auditable.

COMMON WRONG ANSWERS Manually typing hex codes and pixel values into CSS, the classic drift source. Letting code be the source of truth while designers edit Figma separately, creating two diverging truths. Skipping the standard format so the pipeline is locked to one tool. Auto-merging token changes with no review.

LIKELY FOLLOW-UPS How do you model primitive versus semantic versus component tokens. How do you handle theming and dark mode in the pipeline. How do you prevent a bad token change from shipping unreviewed.

ONE CONCRETE EXAMPLE A designer updates the brand color in Figma Variables. A CI job exports DTCG JSON, Style Dictionary regenerates CSS custom properties and a TS theme object, and a bot opens a PR showing the diff; once an engineer approves, the new color flows to every component without anyone editing a hex by hand.