How would you structure a multi-theme color system in Figma and CSS?

WHAT THIS TESTS: 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.

A GOOD ANSWER COVERS: 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.

COMMON WRONG ANSWERS: 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.

LIKELY FOLLOW-UPS: 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?

ONE 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.

Source: ux-design-agency.co.uk