Component properties are what turn a single Figma component into the foundation of a real design system. Instead of creating ten different button components for every possible variation, properties allow a single component to expose a menu of choices that guide how the component should be used. Learning the four property types and how they work together is one of the highest leverage skills for any Figma user, whether as a consumer of a design library or as the person building one.
- Variant properties create different design variations of a single component, like color or appearance, that users can pick from a menu.
- Text and boolean properties expose friendly controls for editing text and toggling visibility without diving into nested layers.
- Instance swap properties let a parent component offer a curated list of child components, such as a set of icons that are appropriate for buttons.
This lesson is a preview from our Figma Masterclass Online. Enroll in this course for detailed lessons, live instructor support, and project-based training.
This is a lesson preview only. For the full lesson, purchase the course here.
The sections below walk through each property type in order, starting with variants and moving through text, boolean, and instance swap. Along the way the discussion covers naming, the component set frame, and the mindset shift that properties encourage when designing for a team or organization.
Why Properties Exist
Without properties, a component gives consumers no guidance about what they are allowed to change. A button that is a component can still have its fill color swapped on an instance, but that freedom can undermine the design system by producing buttons in colors that were never intended. Properties turn the right sidebar into a menu of curated choices. When a consumer of the component selects an instance, they can see exactly which settings were designed to be changed and which were not. The restaurant menu analogy fits well, because the goal is to guide users toward intended choices rather than to enforce strict rules.
Variant Properties
Variant properties create different design variations of a single component. Adding a variant to an existing main component creates a component set, which is a container that holds every variant as a sibling. Each variant can be modified independently, so one version might use a black fill and another might use a brown fill. Naming matters here, because the property itself should describe the attribute being varied, such as Color, and the values should describe the actual variation, such as Black, Brown, and Gray. Naming can also be abstract, using terms like Primary and Secondary, which is often a better long term choice than literal color names because it communicates intent.
Combining Multiple Variant Properties
A single component can have multiple variant properties. Duplicating a row of color variants and applying a different appearance, like swapping fill and stroke to produce an outlined version, creates a second axis of variation. Adding a second variant property named Appearance with values like Solid and Outlined gives the consumer the ability to mix and match colors and appearances freely. Figma needs enough unique combinations of property values to identify each variant, which is why every combination must be distinct.
A few tips that keep variant sets manageable:
- Use abstract names like Primary and Secondary when the variation represents hierarchy rather than literal visual attributes.
- Keep the component set frame organized in a grid so related variants sit near each other.
- Add variant properties sparingly, because every new combination multiplies the number of variants that need to exist.
- Treat the default variant as the most commonly used option, because it will be the one consumers start with.
Text Properties
Text properties might seem redundant at first because text inside a component can already be edited on an instance, but the real purpose is to communicate intent. Exposing a text property signals to consumers that the text is meant to be changed, and it surfaces a friendly input field in the right sidebar instead of requiring a double click into nested layers. Adding a text property starts by selecting a text layer and using the Select Matching Layers action, which grabs every text layer inside the component set at once. That ensures the text property applies across every variant, which is usually what designers want.
Boolean Properties for Visibility
Boolean properties toggle the visibility of an element. A common use is an icon that should be optional, where consumers can decide whether to show or hide it. The workflow is to nest an instance of an icon component inside the main component, select that nested instance across all variants with Select Matching Layers, and then click the add property button next to the visibility toggle. Naming the property something descriptive, like Has Icon, makes the control self explanatory in the right sidebar. Auto layout handles the rest, because a button set to hug contents will resize when the icon is hidden or shown.
Instance Swap Properties
Instance swap properties take the idea further by letting consumers replace a nested component instance with another component from a curated list. A button with an optional icon can expose an instance swap property that offers a preferred list of button appropriate icons, like an arrow, an envelope, or a download icon. Consumers can pick from that list directly in the right sidebar without digging through the full asset library, and the swap works regardless of which color or appearance variant is currently selected. The key requirement is that the nested element must already be a component instance, not a raw vector, which is why copying and pasting the instance rather than dragging its underlying vector is important during setup.
Scaling Into a Design System
The combined effect of all four property types is a component that encodes design intent directly into the asset. A single button with color variants, appearance variants, a text property, a has icon boolean, and an instance swap for the icon is flexible enough to cover every reasonable use while guiding consumers away from unintended customizations. When published as a library, that same button becomes available across every file in a team or organization, and every consumer benefits from the same guardrails. Properties are what transform a scattered collection of components into a coherent design system that scales.
