How would you structure a multi-theme color system in Figma and CSS?
Token architecture bridging Figma modes to code.
Primitives and Semantic collections with theme modes; pipeline to CSS variables; components use semantic tokens only.
What's really being asked
This question evaluates whether you understand design token architecture as a bridge between design and engineering, not just as a naming convention. The interviewer wants to see that you can structure Figma Variables into layered collections, use modes for theme switching, and translate that same mental model into code without breaking the systematic relationship between design and production. It also tests your grasp of accessibility, specifically how high-contrast requirements should influence token structure rather than being bolted on later.
The full answer
First, a two-tier Figma structure: a Primitives collection containing raw values like blue-600, and a Semantic collection where variables reference primitives with names like text-primary or surface-elevated. The Semantic collection defines modes for Light, Dark, and High-Contrast so the same component references swap values automatically. Second, an extraction pipeline: using the Figma Variables REST API or Tokens Studio to export JSON, then transforming it through Style Dictionary into platform-specific outputs. Third, a code implementation that mirrors Figma modes. In CSS, define custom properties on root and redefine them under selectors like data-theme dark so var(--color-text-primary) resolves differently per theme. In CSS-in-JS, use theme objects exposing the same semantic keys. In Tailwind, reference CSS custom properties in the config rather than hardcoding values, giving utility classes that respond to theme changes without rebuilding CSS. Fourth, component-level discipline: UI code imports only semantic tokens, never primitive hex codes, ensuring themes change without markup duplication.
The mistakes people make
A flat token list with no separation between primitives and semantics forces you to rename tokens when brand colors change. Hardcoding hex values inside components or creating separate component variants for each theme defeats the purpose of tokens and creates maintenance debt. Proposing to rebuild or recompile the entire stylesheet for theme switching ignores runtime requirements and breaks CSS custom property mode mirroring. Ignoring high-contrast as a distinct mode rather than an afterthought is a major accessibility red flag.
What usually comes next
How would you handle alpha variants or opacity scales without exploding the token count? What is your strategy when designers add one-off colors that do not map to existing primitives? How do you keep Figma and code in sync as tokens evolve? How would you structure spacing or typography tokens using the same primitives-to-semantic pattern?
A concrete example
In Figma, you create a Primitives collection with color-blue-600 set to 2563eb. In the Semantic collection, you create color-text-primary and set its Light mode to reference color-neutral-900, its Dark mode to reference color-neutral-100, and its High-Contrast mode to reference color-black. In CSS, you emit root with --color-text-primary set to 111827, then under the selector data-theme dark you set it to f3f4f6, and under data-theme high-contrast you set it to 000000. A button component uses color: var(--color-text-primary). When the data-theme attribute changes, the button updates instantly without re-rendering or duplicated markup.
Interview question
Which CSS strategy best mirrors a Figma two-tier token system with Light, Dark, and High-Contrast modes?
- a.Components reference primitive CSS variables directly, using media queries to update primitive values per theme.
- b.Compile separate stylesheets per theme and serve the appropriate file based on the active theme.
- c.Inject High-Contrast colors as overrides at the component level after the base Light or Dark theme loads.
- d.Semantic custom properties reference primitive variables and are redefined under theme attribute selectors like [data-theme="dark"].Correct
Why? this is the answer
Redefining semantic custom properties under theme selectors preserves the abstraction where components use only semantic tokens, matching Figma's mode behavior. Option A breaks this architecture by letting components bind directly to primitives, creating maintenance debt when brand values change.
Just read this? Test yourself on what you have been reading.
Read the original → ux-design-agency.co.uk
- #figma
- #design-tokens
- #css
- #theming
- #component-library
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 figma — each one lists the topics its interview covers.
See open roles