How do you structure and maintain a Figma component library for scale?

WHAT THIS TESTS: The interviewer wants to know if you can architect a Figma environment that scales beyond a single designer. They care about your mental model for component taxonomy, your familiarity with Figma-specific features like variants and component properties, and your ability to reduce friction for developers who consume the design system.

A GOOD ANSWER COVERS: First, file and library structure. You should mention splitting foundations like color and typography into a base library, then consuming those in a component library to avoid circular dependencies. Second, component strategy. Explain using variants for mutually exclusive states like button hierarchy, and boolean properties for independent toggles like icons or loading spinners to keep the component set flat. Third, auto-layout and constraints. Show you think responsively by nesting auto-layout frames and setting constraints so components reflow correctly. Fourth, documentation and developer handoff. Mention adding descriptions to components and variants, using section annotations, and ensuring Dev Mode exposes relevant properties, CSS, and measurements. Fifth, governance. Describe naming conventions like category slash component slash state, a contribution process, and regular library audits to deprecate unused variants.

COMMON WRONG ANSWERS: A major red flag is treating Figma like a static mockup tool. If you only talk about visual consistency without mentioning component properties or instances, you signal a pre-component workflow. Another mistake is creating a variant for every possible combination instead of using boolean properties, which leads to an unmaintainable explosion of components. Suggesting designers manually copy and paste elements rather than using published libraries also shows a lack of systems thinking.

LIKELY FOLLOW-UPS: The interviewer might ask how you would handle theming or dark mode, which tests whether you know about Figma variables and modes. They could ask how you prevent breaking changes when updating a library, which is a chance to discuss instance overrides, backwards-compatible property additions, and clear release notes. They might also probe how you measure adoption, such as tracking library analytics or conducting designer surveys.

ONE CONCRETE EXAMPLE: Imagine building a button component for a growing SaaS product. You would create a main component with auto-layout for padding and text truncation. You would define variants for primary, secondary, and tertiary hierarchy. You would add boolean properties for an icon prefix, an icon suffix, and a loading state. You would set text and color styles from a published base library so that a single token update propagates everywhere. In Dev Mode, a developer can see the component name, inspect spacing values, and copy CSS without guessing at rem values. When the product adds a destructive action, you add a new variant and update the documentation description rather than creating a one-off custom button.