How do you change a nested Button's state from a Card instance?

WHAT THIS TESTS: This question tests whether you understand Figma component properties as the mechanism for exposing nested instance controls at the parent level. Specifically, it checks if you know that variant properties can be applied to nested instances inside a main component so that consumers of the parent component can change the child state without drilling into layers or detaching anything. It also surfaces whether you think in terms of design system scalability rather than one-off hacks.

A GOOD ANSWER COVERS: First, the candidate should state that you work on the Card main component, not an instance. Second, they should describe selecting the nested Button instance inside that Card main component and applying a variant property to it. Third, they should explain that this exposes the Button state toggle directly in the properties panel of any Card instance. Fourth, a strong answer notes that this preserves the link to the Button main component and avoids layer overrides. Finally, the best answers mention that you can add descriptions to the property to document intent for other designers.

COMMON WRONG ANSWERS: A major red flag is suggesting that you detach the Button instance inside the Card so you can edit it freely; this breaks the design system link and prevents updates from propagating. Another wrong pattern is recommending that you create a duplicate set of Card variants for every possible Button state, which causes a combinatorial explosion and maintenance nightmare. Some candidates also suggest using layer overrides by manually selecting the nested Button on every Card instance, which is fragile and hides the control from the properties panel. Finally, saying you cannot do this in Figma and must accept static nested components shows a gap in knowledge of modern component properties.

LIKELY FOLLOW-UPS: An interviewer might ask how you would handle this if the Button had multiple properties you wanted to expose, such as an icon swap and text content. They could also ask what happens if you later add a new variant to the Button main component, or how you would restrict which Button states are available from the Card level. Another follow-up is asking how slot properties differ from this approach if the Card needs to accept any component, not just a Button.

ONE CONCRETE EXAMPLE: Imagine a Card main component that contains a nested Button instance used for a call to action. The Button has two variants: default and hover. Inside the Card main component, you select the Button instance and create a variant property applied to it, naming it CTA State. Now, when a designer places an instance of the Card on a page, the right panel shows a CTA State dropdown with default and hover options. Changing it on the Card updates the nested Button instantly without expanding the Card layer tree or detaching the Button. If the Button library updates, the nested instance stays linked and receives those updates automatically.