How would you structure Figma colors for light and dark themes?

WHAT THIS TESTS: This question tests whether you can architect a scalable theming layer using Figma's raw-value primitives rather than static artifacts. The interviewer wants to see that you understand how to separate brand colors from semantic intent and how to use context-aware value switching. They also care that you know the relationship between Figma's color styles and its newer variable system, specifically that variables are the raw engine for mode changes while styles can consume those variables.

A GOOD ANSWER COVERS: A strong answer starts by defining primitive color variables for the brand palette because color variables use solid color values and help organize the brand palette. Next, create semantic color variables that alias those primitives so you can implement design tokens; this lets a single semantic name carry different raw values for light and dark modes because variables change value depending on context. You should then explain that these variables live in a collection that can be published to a team library so updating a variable value updates designs across files. Crucially, note that color variables can be applied to color styles, fill colors, gradient stops, shadow effects, and stroke colors, meaning styles can reference variables rather than storing static hex codes. The role of styles is therefore to handle properties like gradient stops or shadow effects where variables are applied, while the mode-switching logic lives in variables because variables are raw values that change depending on context. This keeps theme switching efficient because you change one mode, not every style instance.

COMMON WRONG ANSWERS: A red flag is proposing to duplicate entire style sets for light and dark modes or manually swap style libraries per theme. Another mistake is saying styles handle the mode switching directly; the reference frames variables as the raw values that change depending on context such as light and dark modes, so styles should consume variables rather than own the switching logic. Candidates also err by suggesting every hex code be a unique variable without aliasing, which destroys semantic clarity and makes maintenance inefficient.

LIKELY FOLLOW-UPS: An interviewer might ask how you would handle a property that variables do not yet support, or how you would onboard a legacy file that uses hard-coded styles. They might also ask how you would structure collections if the system later adds responsive spacing or text themes.

ONE CONCRETE EXAMPLE: Imagine a button background. You create a primitive color variable named brand-blue with a solid color value of 0055FF. You then create a semantic variable named button-primary-bg and alias it to brand-blue. In the variable collection, you define two modes: Light and Dark. In Light mode, button-primary-bg stays aliased to brand-blue. In Dark mode, you change the alias so button-primary-bg points to a primitive variable for a lighter blue. When a designer toggles the mode on the frame, every button using that semantic variable updates instantly because the raw value changes with context. The color style for the button fill references the semantic variable, so the style itself does not need a duplicate dark variant.