How do Figma variants influence component code structure?

WHAT THIS TESTS: This question tests whether you can bridge design tools and production code by treating Figma variants as a specification for a component contract rather than a visual mockup. Interviewers want to see that you understand which variant properties should become public props, which should be internal state, and how to avoid brittle hardcoding when translating design intent into a reusable UI component.

A GOOD ANSWER COVERS: First, map variant properties to a semantic prop interface. Properties like size, type, or icon position become explicit props with constrained values, while interactive states like hover, pressed, or focused should usually remain internal concerns handled by CSS or the component's own state logic. Second, inspect the full variant matrix to identify the complete set of combinations the designer intended; this prevents you from shipping a component that only handles the happy path shown in the mock. Third, prioritize the names and structure of variant properties over raw visual values. A property named size equals small tells you to map to a design token or spacing scale, whereas extracting width equals 32 pixels leads to fragile code. Fourth, flag missing or redundant variants. If the design shows state equals hover but not disabled, ask whether that omission is intentional or an oversight before you build.

COMMON WRONG ANSWERS: Treating every variant permutation as a separate component, such as building ButtonHoverSmallPrimary and ButtonDefaultLargeSecondary, reveals a failure to abstract. Copying hex codes, font sizes, or pixel dimensions directly from the variant properties panel instead of mapping to tokens shows you do not understand design system architecture. Another red flag is exposing hover or active states as top-level props that consumers must manually toggle, which pushes interaction complexity to the parent and breaks accessibility.

LIKELY FOLLOW-UPS: How would you handle a component with nested variants or boolean properties in Figma? What do you do when the variant matrix explodes combinatorially, for example with ten colors across five sizes and four states? How do you represent responsive behavior or auto layout constraints that are not explicitly captured as variant properties?

ONE CONCRETE EXAMPLE: Imagine a button with variants for size equals small, medium, or large, type equals primary or secondary, and state equals default or hover. In code, you build a single Button component with props size and variant. The size prop maps to tokenized padding and font size scales. The variant prop maps to color and border tokens. The state equals hover variant is discarded as a prop and instead implemented with CSS hover pseudo-classes or an internal useHover hook. When the designer later adds a tertiary type, you only extend an enum rather than creating a new file.