Explain the difference between a Main Component and an Instance in Figma

WHAT THIS TESTS: This question evaluates whether you understand the core abstraction that makes Figma scalable for design systems. Interviewers want to know if you grasp the difference between a master definition and its distributed copies, and more importantly whether you understand how the override system preserves local context while allowing global changes. At a senior level, they are listening for awareness of design system governance, component library hygiene, and the tradeoffs between strict consistency and flexible reuse.

A GOOD ANSWER COVERS: First, define the Main Component as the canonical source of truth that lives in a dedicated page or library file and stores the full set of properties including layout, color, typography, and nested components. Second, define an Instance as a lightweight proxy object placed on a design canvas that maintains a live link back to the Main and inherits all of its properties by default. Third, explain the update mechanism: when you edit the Main, Figma pushes those changes to every Instance immediately unless a specific property has been overridden locally on that Instance. Fourth, mention that overrides are granular, meaning you can change text, color, or visibility on an Instance without breaking the link, and those overridden fields will not be overwritten by subsequent Main updates unless you explicitly reset them.

COMMON WRONG ANSWERS: A major red flag is describing an Instance as an unlinked duplicate or a static copy, which suggests you have been working around components rather than with them. Another mistake is claiming that all overrides are lost when the Main Component changes; this shows confusion between Figma and older vector workflows. Saying that you need to manually sync or republish Instances is also incorrect because the link is automatic. Finally, avoid suggesting that every Instance must look identical; that misses the entire point of the override model.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle a breaking change to a Main Component that affects hundreds of Instances across multiple files. They might probe on nested components and how overrides behave when a Main contains Instances of another component. You could also be asked about branching strategies for component libraries, how to use component properties and boolean variants to reduce the need for overrides, or when to detach an Instance and why that creates technical debt.

ONE CONCRETE EXAMPLE: Imagine you are building a button component. The Main Component defines a 48 pixel height, a blue fill, and a label that reads Button. You place ten Instances across different mockups. On three of those Instances, a designer overrides the label text to read Save, Cancel, and Submit. Later, the design system team updates the Main Component to use a 44 pixel height and a darker blue. All ten Instances receive the new height and color immediately. The three Instances keep their custom labels because text was overridden locally, while the remaining seven still show the default Button text. If the team had also changed the text layer name in the Main, the text overrides on those three Instances would have been lost because Figma matches overrides by layer name.