Why use button variants instead of separate components per state?

WHAT THIS TESTS: This question evaluates whether you understand design system architecture in Figma beyond surface-level organization. The interviewer wants to know if you can articulate why combinatorial explosion is a problem, how variant properties preserve flexibility, and how component sets bridge the gap between design assets and code. It is fundamentally a question about scalability and cross-functional collaboration, not just tidiness.

A GOOD ANSWER COVERS: A strong response hits four points in order. First, the math of combinatorial explosion: if you have three properties with roughly four values each, you end up with sixty-four discrete permutations that would each require a separate component without variants, quickly overwhelming a library. Second, independent property mixing: by splitting attributes like State and Style into distinct properties, designers can combine them orthogonally instead of relying on pre-baked permutations, which matches how code components accept props. Third, developer handoff alignment: variant properties in Figma map directly to component props in React, Vue, or CSS custom properties, so engineers do not have to guess which discrete component corresponds to which prop combination. Fourth, navigability and error reduction: component sets group related variants under a single roof, making it easier to switch states without detaching or swapping instances, which preserves design system integrity across projects.

COMMON WRONG ANSWERS: Watch out for vague answers that say variants are just cleaner or save space without naming structural benefits. Another red flag is suggesting one mega-property like Style equals Primary Large instead of separating Type and Size, which Figma explicitly recommends against because it removes flexibility. Candidates also stumble when they treat variants as only an organizational wrapper and miss the handoff story entirely. Finally, failing to acknowledge how this scales as the design system grows signals a lack of real-world systems thinking.

LIKELY FOLLOW-UPS: An interviewer might push deeper by asking how you would structure variant properties for a complex component like a data table row or card. They may ask at what threshold variants become unwieldy and should be split into separate components. You might also be asked how to handle content variations such as leading icons or dynamic labels within a variant system, or how you keep Figma variant names in sync with code component props during handoff.

ONE CONCRETE EXAMPLE: Imagine a button with three properties: Type with values Primary, Secondary, and Destructive; Size with Small, Medium, and Large; and State with Default, Hover, Active, and Disabled. As separate components, that is thirty-six individual buttons to maintain. As a variant set, it is one component set with three properties. When a designer needs to switch from Primary-Large-Default to Secondary-Large-Hover, they toggle two dropdowns instead of swapping instances and reapplying overrides. For developers, the Type, Size, and State values correspond directly to props in a React button component, making inspection and translation straightforward.