Figma's component system becomes incredibly powerful once you move beyond basic component creation. Advanced techniques like nested components, component properties, and the slots pattern let you build flexible, maintainable design systems that scale with your team.
Nested Components
Nested components are components placed inside other components. This is the foundation of scalable design systems. Instead of creating a separate component for every variation, you compose complex components from simpler building blocks.
Example: A card component might contain:
- A nested Avatar component for the user image
- A nested Badge component for status indicators
- A nested Button component for the call to action
When you update the Avatar component, every card that uses it updates automatically. This cascading behavior means you maintain a small set of atomic components that combine into hundreds of variations.
Practical tip: Think in layers of abstraction. Start with primitive components (icons, text styles, color tokens), compose those into mid-level components (buttons, inputs, badges), then assemble those into complex components (cards, navigation bars, modals).
Component Properties
Component properties replaced the old approach of using variants for every toggle. Instead of creating separate variants for "with icon" and "without icon," you use properties that can be configured directly on each instance.
The four property types:
- Boolean property — Toggles an element's visibility. Use this for optional elements like icons, badges, or descriptions. When toggled off, the element is hidden and surrounding content reflows automatically with auto layout.
- Text property — Exposes a text field that can be edited directly in the properties panel without entering the component. Perfect for labels, headings, and placeholder text.
- Instance swap property — Lets you swap a nested component for any other component from a specified set. This is how you make icon slots, avatar slots, and interchangeable elements.
- Variant property — Switches between predefined visual variants like size (small, medium, large) or state (default, hover, disabled).
Practical tip: Name your properties clearly and consistently. Use format like "Show Icon" for booleans, "Label" for text, "Icon" for instance swaps, and "Size" for variants. Good naming makes components self-documenting.
Boolean Properties in Practice
Boolean properties are the simplest but most frequently used property type. They clean up your variant sets dramatically.
Before boolean properties, a button component with optional left icon, optional right icon, and optional subtitle would need 2 x 2 x 2 = 8 variants just for those toggles, multiplied by every size and state variant. With boolean properties, you need just one variant per size/state combination, with three toggleable booleans.
Setup steps:
- Select the layer you want to make toggleable (e.g., an icon instance)
- In the design panel, click the component property icon next to the visibility toggle
- Choose "Boolean" and name it descriptively (e.g., "Show Left Icon")
- Set the default value to true or false
When consumers of your component use it, they see clean toggle switches in the properties panel instead of a long list of variant options.
Instance Swap Properties
Instance swap properties create flexible "slots" where different components can be plugged in. This is the most powerful property type for building composable systems.
Common use cases:
- Icon slots — Let users swap between any icon in your icon library
- Avatar slots — Allow different avatar styles or placeholder images
- Action slots — Let a card's action area contain a button, a link, or a menu trigger
To set up instance swap properties, the slot must contain a component instance. You can optionally set a "preferred values" list to suggest commonly used swaps, which keeps the swap menu manageable in large libraries.
The Slots Pattern
The slots pattern takes instance swap properties to their logical conclusion. Instead of trying to anticipate every configuration a component might need, you create generic slots that accept any component.
Example: A list item component with three slots:
- Leading slot — Can hold an icon, avatar, checkbox, or thumbnail
- Content slot — Can hold a single-line label, a label with description, or custom content
- Trailing slot — Can hold a chevron, a switch toggle, a badge, or a timestamp
This approach dramatically reduces the number of variants you need while giving consumers flexibility to create configurations you never anticipated.
Practical tip: Create a set of "slot placeholder" components — simple rectangles with labels like "Replace me" — that serve as defaults in your slots. This makes it obvious to consumers that the slot is meant to be swapped.
Key Takeaways
- Use nested components to build complex UI from simple, reusable building blocks
- Component properties (boolean, text, instance swap, variant) reduce variant explosion
- Boolean properties replace the need for "with/without" variant pairs
- Instance swap properties create flexible slots for interchangeable content
- The slots pattern maximizes flexibility while keeping your component library manageable