How would you establish design tokens in Figma and sync with production?
Tests design-to-code architecture. A strong answer outlines primitive-to-semantic tokens in Tokens Studio, W3C DTCG JSON synced to Git, and Style Dictionary transforms in CI/CD. Red flag: manual exports or treating Figma styles as the source of truth.
What's really being asked
This question tests whether you can build a bidirectional design-to-code pipeline rather than a static handoff. Interviewers want to see that you understand token taxonomy, Figma tooling, git-based versioning, and automated transformation into platform-specific code. Senior candidates are expected to discuss governance, branching strategy, and how to prevent drift between design and production.
The full answer
First, establish a three-tier taxonomy: primitive tokens for raw values like base colors and spacing units, semantic tokens for context such as action-primary-background or text-error, and component tokens for specific UI elements. Second, implement these in Tokens Studio for Figma using the W3C DTCG JSON format to ensure future interoperability. Third, configure remote token storage by syncing to a Git provider like GitHub or GitLab so the JSON file lives in the same repository as the codebase, making it the single source of truth. Fourth, set up a transformation pipeline using Style Dictionary or SD Transforms in CI/CD to compile tokens into CSS custom properties, JavaScript objects, or mobile asset catalogs on every pull request. Fifth, export tokens back into Figma as Variables or Styles so designers consume the same values engineers use, and use branch switching in Tokens Studio to experiment without breaking production.
The mistakes people make
Proposing that designers manually copy hex codes or spacing values into a shared spreadsheet that developers later transcribe. Treating Figma Styles as tokens without an underlying JSON schema or version control. Suggesting a one-way export from Figma to code with no automated sync, which guarantees drift within weeks. Ignoring the distinction between primitive and semantic tokens, which leads to brittle systems where a brand color change requires hundreds of manual updates.
What usually comes next
How would you handle theming for dark mode or multi-brand white-labeling? What is your rollback strategy if a token change breaks the UI in production? How do you manage token ownership between designers and engineers? What do you do when a platform like iOS needs a different naming convention than web?
A concrete example
At a previous company, we stored tokens in a GitHub repository connected to Tokens Studio. Designers edited tokens in Figma and pushed to a feature branch. A GitHub Action ran Style Dictionary to generate CSS and Swift files, then opened a pull request for engineering review. When the PR merged, the tokens were versioned and released through npm. This reduced design-to-code handoff from three days to under an hour and eliminated color drift between Figma mocks and the live application.
Interview question
In a scalable design-to-code token architecture, what is the primary benefit of maintaining separate primitive and semantic token tiers?
- a.It lets Style Dictionary skip primitive values and generate platform code only from semantic aliases to reduce build times
- b.It allows primitive tokens to be owned by the design team and semantic tokens by engineering to clarify handoff responsibilities
- c.It prevents brittle systems by letting a base brand change cascade through semantic references without manually updating hundreds of componentsCorrect
- d.It ensures that Figma Styles remain editable by designers while locking semantic mappings in the Git repository
Why? this is the answer
The card states that conflating primitive and semantic tokens creates a brittle system where a brand color change requires hundreds of manual updates, so separation enables automatic cascading. Option D is tempting because it mentions Git and Figma, but the tiered taxonomy is about abstraction and cascade, not locking permissions.
Just read this? Test yourself on what you have been reading.
Read the original → docs.tokens.studio
- #design systems
- #figma
- #design tokens
- #frontend architecture
- #ci/cd
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on design systems — each one lists the topics its interview covers.
See open roles