Figma began deprecating simplified instances on March 23, 2026. Since then, every instance shows all component properties and layers by default (Figma Help Center and Community Support, 2026).
Every property name and layer name inside a main component is now visible to anyone who uses it. If your library has a Rectangle 4 or a Property 2 hiding in there, people will see it.
How should Figma components be named?
Call a component by what it is and skip how it looks today. Slashes group related components into a path, and the names should match whatever developers call things in code. Settle casing, terminology and property names early.
Figma’s component management tips say it is much easier to establish naming conventions at the start than to fix them later.
Name the thing, not its appearance
A name like blue-large-button turns into a problem the first time the color or size changes. Call it Button and let the properties carry the rest.
The vocabulary only needs picking once, but it needs picking before the library grows. Figma’s component management tips list these choices to make up front:
- Casing, whether Title Case, lower case or camelCase
- Which words get abbreviated, if any
- Modal or dialog, icon or symbol, notification or toast
- Boolean phrasing, such as Has Icon, Show Icon or Icon Visible
- Value naming, SM, MD, LG or Small, Medium, Large, and Hover or Hovered
Properties follow the same logic. Size on one component and Dimensions on another, both describing the same attribute, is how a library starts to feel sloppy.
Match names to code
Figma’s own example is Button in the design file and <Button> in code. If one side says CTA and the other says <Action>, every handoff invites a translation error.
Developers see these names in the right sidebar while working in Dev Mode, so a mismatch stands out to them right away.
Arc XP’s design team takes this literally and names its Text Field component TextField, the same as the React tag.
Have you seen the latest Figma statistics?
Discover comprehensive Figma statistics including revenue growth, market share, user demographics, and funding data.
Check them out →Compound, the design system from Phoenix Group, also lines property names up with the coded component where it can, and wants boolean properties to have unique names.
Slash naming and the Assets panel
Every slash adds a level to the Assets tab and to the instance menu.
- button/primary/default
- button/primary/hover
- button/secondary/default
With the Show subfolders setting on, the Assets panel displays that path as nested folders. I’d take one slightly long path over a flat list of 200 components every time, since big libraries get much easier to scan.
The same structure turns loose components into variants. Text before the first slash becomes the component set name, each further slash becomes a property, and every component being combined needs the same number of slashes (Figma Help Center).
Figma labels the generated properties Variant, Property 2, Property 3. Rename them right away.
Layer names matter too. card-thumbnail tells a developer something. Rectangle 4 doesn’t.
How to structure a component library from base elements up
Work in layers, with base elements at the bottom and everything else assembled from them. Each level gets its own page or frame, base components stay out of the published library, and the file hierarchy should mirror what designers see in the Assets panel.
Levels borrowed from Atomic Design
Most teams already sort components this way, named or not. The hierarchy comes from the Atomic Design model by Brad Frost, with its atoms, molecules and organisms.
- Icons, avatars and dividers sit at the base. Each has a single purpose and no nested components.
- Buttons, inputs and tags are the next level up, built from those base elements.
- Headers, cards and form rows are patterns, built from components.
Figma’s own best-practices guide uses a navigation header to explain nesting. The logo, avatar, buttons and menu items are each an instance of another component.
Pages, frames and set grouping
By default, the Assets tab path follows file, page, frame, and pages appear alphanumerically instead of in file order (Figma Help Center). GitLab’s Pajamas design system goes with one page per component, frames named for the category or group, and variant layers written as comma-separated Property=Value pairs (GitLab design documentation).
Pick one grouping mechanism. Figma builds the Assets path from file, page, frame and component name, so describing the same level in two places (a frame title and a slash name, say) can show that level twice in the Assets panel.
Component sets add one hard rule. They hold components only. Annotations go beside the set as text layers, outside the dashed purple border.
Base components behind variant sets
A base component holds every element a family of variants might need. Each variant hides what it doesn’t use, and one edit to the base reaches all of them, according to Danny Sapio on UX Collective.
Put a period in front of the base name and it stays out of the published library. Figma’s help documents the period for components, and a period or underscore for variable collections, while a 2025 forum thread reports that an underscore no longer hides a component. Figma also lets you right-click an asset and choose Hide when publishing, which works for styles, components and variables, including primitives consumers should never pick.
Auto layout settings every component needs
Every component frame uses auto layout, with resizing set on each child and padding and gap entered as deliberate values. Arc XP’s guidelines make this a requirement, asking for auto layout wherever it applies and every constraint and resizing option configured.
The mechanics live in a separate Figma auto layout guide. For components, what matters is which setting goes where.
Resizing per element
- Hug contents suits frames that wrap their children. Figma’s own example is a button that grows and shrinks with its text label.
- Fill container is for children that stretch into the parent’s free space, like an input inside a form row.
- Icons, avatars and anything else with a set dimension get a fixed width or height.
- A minimum and maximum go on a frame that otherwise hugs or fills, so a long label can’t stretch it forever.
Hug applies to auto layout frames, and Fill applies to their children (Figma Help Center).
Spacing and hidden layers
Padding and gap should come from spacing tokens, not typed pixel values. Arc XP says to apply the design system’s tokens instead of raw values, and its own example maps every color to a token, so every component draws from the same set.
One failure mode catches teams out. When padding has to differ because a boolean property hides a layer, Phoenix Group’s Compound guidance calls it a known limitation and says to create a separate variant for it.
Which variant setup keeps component sets manageable?
Variants should cover the visual or structural differences users switch between, like style, size and state. Content-level changes belong to component properties, which keeps the set from multiplying.
Figma’s component management tips draw the same line.
Where variants stop being the right tool
Different icons don’t belong in one component set.
Figma’s variants documentation advises against it, and its best-practices guide recommends a nested icon instance you swap instead. Sizes of the same icon are the exception, and those can be variants.
Property order and naming
Arc XP orders variant properties from most to least impactful and keeps that order on every component. Component-specific properties go between State and Size.
- Mode comes first, Light or Dark.
- Type is second, such as icon on left, icon on right or both.
- State follows, with values like empty, selected and focus.
- Size is always last, Large or Small.
Joystream’s Figma guidelines reach a similar place from the other direction, putting visual properties first and then sizing and functionality. Two independent teams, one rule of thumb. Size late, same order everywhere.
Order is a Figma mechanic too. Reordering properties rewrites the variant names to match, and variant properties always sit above every other property type in the right sidebar.
Whichever variant sits in the top-left corner represents the whole set in the Assets tab and is what a new instance starts as.
How many variants is too many
Older practitioner guidance says every permutation has to exist as its own variant. Figma’s current documentation says each variant must be a unique combination of values, but it doesn’t require a component for every possible combination.
Leave gaps only for combinations nobody needs, and test the property dropdowns before publishing.
Compound goes a step further and splits components when variants can’t express the logic of the coded version. Figma itself says variant properties can map to code props, so the divergence is a style call. Split where the code splits.
For the conversion steps, this walkthrough on creating variants in Figma covers combining existing components into a set.
Figma documents a few hard limits as well:
- Two variants with the same combination of values trigger a conflicted value error, even when they look different.
- A mistyped property or value triggers a corrupted variant error.
- Deleting the only variant property deletes the whole component set.
- Adding an instance imports every variant in the set, so very large sets slow Figma down (Figma Help Center).
What does each component property type control?
Booleans toggle layer visibility and text properties expose editable strings. Instance swap properties replace a nested instance, and variant properties switch between predefined versions. Figma’s Help Center also lists a slot property for open content areas.
| Property type | Controls | Documented limit |
|---|---|---|
| Boolean | Show or hide a layer | Visibility only; merging two components loses the prototype link between them |
| Text | An editable string | No rich text; list styles drop if edited from the right panel |
| Instance swap | Which nested instance appears | Preferred instances narrow the choices |
| Variant | State, size, color | Component sets only; cannot detach from a nested layer |
| Slot | Open content area | Available on all plans; launched in open beta in March 2026, and current Help Center articles carry no beta label |
Boolean and text properties
The saving is easy to see in numbers. A button with 3 types, 4 states and icon options on either side needed 48 variants before component properties and 12 after (Prototypr, 2022).
That’s why an optional icon is a boolean on the icon layer and not a variant. Figma’s documentation uses the same example.
Booleans have one trap. A prototype in Figma connects two objects, so folding two components into one boolean-driven component removes the thing the connection was attached to.
Text properties have a catch of their own. If a text layer carries a bulleted or numbered list style, editing the string from the right panel removes it, so edit on the canvas to keep it.
Instance swap and preferred instances
Figma’s example is an icon library of over 100 icons, with only 8 approved for one icon button.
Preferred instances put those 8 at the top of the swap menu, so designers stop guessing. Defaults can come from any component in the file or from libraries added to it.
Exposed nested instances work the other way around. They surface a nested component’s properties in the parent’s panel, so nobody has to deep-select layers just to change a nested button. The option only appears once a nested instance already has a component property applied, or another nested instance is already exposed.
What changed with simplified instances
The March 23, 2026 deprecation of simplified instances changed what consumers see in two places.
- All properties appear in the Properties panel on the right.
- Layers that simplified instances used to hide now appear in the Layers panel.
Complexity is no longer hidden from consumers, so layer and property names matter more. Dev Mode adds a component playground (Open in playground) where developers test property combinations without touching the design.
Variants, instance swaps or slots: which one fits?
Match the mechanism to how much freedom the component should allow. Variants cover states and types, and an instance swap property handles a single replaceable element. Anything that changes in count or layout is a job for a slot.
Figma’s Help Center frames this as a spectrum from rigid to freeform. The table places each option on it.
| Mechanism | Best for | Freedom | Documented limit |
|---|---|---|---|
| Variants | States, sizes, types | Low | Meant for varying states, not for imitating repeating content |
| Instance swap property | One replaceable nested element | Low | One instance at a time; nested layout stays locked |
| Slot | Modals, cards, lists | High | No component properties on layers inside the slot |
| Separate components | Logic variants cannot express | Not applicable | A longer Assets panel to search |
The table draws on the Figma Help Center and Compound (Phoenix Group).
A decision rule that holds up
Start from the guardrail the component needs, not from the feature you like best.
- A fixed set of states or sizes? Variants.
- One child that swaps for another is an instance swap property.
- Content that varies in count or arrangement needs a slot.
- If variants can’t express the behavior, make a separate component.
Figma’s example for an instance swap is a browser tab with one website icon that stays to the right of the label. The swap property limits it to one instance and blocks changes to dimensions and position.
A modal reused for messaging and settings screens, and for confirmations too, is where a slot earns its place. Padding, border radius and shadow stay consistent while the content varies, and the instance still receives library updates when the main component changes.
Slot settings that work as guardrails
Figma’s own limits example is an avatar group slot capped at five layers, because the circles crowd each other past that.
The limits guide rather than block. Go past one and the label turns orange with a warning, but the designer can keep working. Slots offer these controls:
- Preferred instances, to curate what goes in
- Only allow preferred instances, for slots like a curated empty-state illustration
- Minimum layer count (a radio group needs two)
- Maximum layer count
- Fill container on the counter-axis by default
Slot limits and availability
Slots began rolling out in open beta in March 2026. As of October 27, 2026, Figma’s slots how-to, its slots fundamentals page, its migration guide and its component properties article all describe slots as available on all plans with no beta banner, and the Help Center’s list of beta features no longer includes them.
Behavior is still changing, though, so check the Help Center before standardizing a library on slots. Of everything in this article, slots are the thing I’d trust least on autopilot.
Component properties can’t be applied to layers inside a slot. Insert an instance that already carries its properties instead, and they persist.
Position, auto layout flow and constraints of a slot change only in the main component.
Basis Technologies’ design system documentation points designers to slot components for adding custom content without detaching. For developer handoff, Code Connect can map slot content into code snippets.
How do variables and styles bind to components?
Bind color, spacing, radius and type values in each component to variables or styles, so one change to a token or mode reaches every instance. Figma’s blog recommends variables for single values that change between modes and styles for grouped values.
The mechanics sit in this Figma variables guide. For components, the question is what to bind.
Which properties accept variables
- Number variables cover corner radius (including individual corners), dimensions with minimum and maximum, font size, weight and line height, padding and gap, stroke weight and opacity.
- String variables handle text content, font family and style, text styles built from variables, and switching component variants in prototypes.
- Boolean variables control layer visibility and the default value of a boolean component property.
- Fills and strokes take color variables.
A text property’s default string can also take a string variable (Figma Help Center).
Styles, variables and the code comparison
Figma compares styles to CSS classes and variables to CSS custom properties.
Effect and layout grid styles can now contain variables, so a single style reacts to modes. Variables can also bind to component instances nested inside a component, which lets a mode change switch the nested variant.
Modes or a Mode variant property?
Arc XP’s guide lists Mode (Light, Dark) as the first variant property, while Figma’s variables documentation treats modes as the mechanism for alternate values.
The difference shows up in set size. A two-value Mode variant property doubles every component set, and a variable mode leaves the set alone.
When should you override, reset or detach an instance?
Override content, reset drift, and detach only when a change can’t be made through an override or a main component edit. Detaching is one-way for that object. It becomes a regular frame, keeps its layers and properties, and stops receiving updates.
What overrides cannot change
Overrides can’t touch any of these:
- Layer order (z-index) inside the instance
- Layer position, including items in an auto layout frame
- Constraints
- Bounds of text layers
Reordering layers means detaching or editing the main component (Figma Help Center).
Which overrides survive a variant switch
Figma keeps a change only when layer names match between the current and the selected variant. For variants, the changed property must also have matched originally, while text overrides need only the same layer name and a similar hierarchy.
Say a fill gets changed from #1BC47D to #F531B3 on a default primary button. It survives a switch to hover primary, because both started with #1BC47D. On hover secondary it disappears, because that variant started with #FFFFFF.
So when overrides vanish, check layer names first.
Resets that are not your fault
Not every lost override traces back to naming. Figma staff have acknowledged related reset problems as known bugs. In April 2025, a Figmate called a text reset issue in the forum a long-standing bug that engineering was working on, with no timeframe for a fix.
When overrides still vanish with matching layer names, reset the instance, reapply the overrides and report the case to Figma Support with a reproduction file.
Reset and detach in practice
Reset restores the main component’s properties, either for the whole instance or for one property.
Anything an override can’t reach belongs in the main component. This guide on editing a component in Figma covers how those changes travel to instances.
Organization and Enterprise plans can track how often instances get detached with library analytics.
How to publish a component library and push updates
Publish from the Libraries icon in the Assets tab. Pick the changes, write a description, choose a destination on Organization and Enterprise plans, and confirm. Consumers then see a blue badge on the library icon and review the update before accepting it.
- Open the Assets tab and click the Libraries icon.
- Under This file, click Publish.
- Write a description of the library’s purpose or the decisions behind the changes.
- Uncheck any added, modified or removed assets you do not want to publish.
- On Organization and Enterprise plans, choose the destination: a team, the whole organization, or a workspace on Enterprise.
- Click Publish and wait for the confirmation.
Before the first publish
- The file needs at least one component, style or variable.
- A file sitting in drafts has to move to a folder first.
- The library takes its name from the source file, so rename the file clearly.
To keep an asset out for good, right-click it in the publish modal and choose Hide when publishing. A greyed-out Publish button usually means nothing changed since the last publish, or the edited assets are hidden.
The description shows up when consumers accept updates and in the file’s version history.
Breaking and non-breaking changes
Adding an optional property, polishing visuals that leave layout and overrides alone, and reworking layers internally without changing property behavior won’t break anything for consumers.
Breaking changes are the ones that bite:
- Removing or renaming a property
- Restructuring variants so existing instances resolve differently
- Renaming layers that users may have overridden
Figma’s own example is an optional supporting-text boolean that is hidden by default, which is non-breaking. Show it by default and every existing instance suddenly displays placeholder text.
Test, announce, retire
Swap an existing instance for the updated component in a file that uses it, then cycle through the property combinations. Organization and Enterprise plans can branch the library to test in isolation.
Keep a changelog with labels such as [UPDATE], [BREAKING] and [DEPRECATED], next to the rest of your design system documentation.
Mark a deprecated component in both its name and its description, point to the replacement, and leave time to migrate. Pulling a component that people still use is the fastest way to lose their trust in the library.
When do these practices break down?
They break down when nothing can be published, when the project lives in one file, when a feature is still changing, and when the safeguard you need sits behind a higher plan. Each of those has a documented limit.
Starter plan and single-file projects
On the free Starter plan you can still create components and styles, but you cannot publish them to a library for other files.
Check the differences between Figma free and Professional before planning a shared library around it.
In a single-file project the payoff shrinks. Slash hierarchies, hidden base components and changelogs matter when several files depend on the library, and cost time when only one does.
Plan-gated safeguards
| Safeguard | Plans | What it protects |
|---|---|---|
| Library branching | Organization, Enterprise | Testing changes before publishing |
| Library analytics | Organization, Enterprise | Judging a change’s reach |
| Publish to team or organization | Organization, Enterprise | Targeting the right audience |
The table comes from the Figma Help Center, specifically the component management tips and the Publish a library article.
Slots and destructive edits
Removing a slot property from a main component is destructive. Layers designers added inside an instance’s slot are removed, and Figma recommends testing the removal in a separate branch.
That recommendation runs into the table above, since branching exists only on Organization and Enterprise plans. A Professional team has to test on a copy of the file instead.
Migration has its own cost. In April 2026, a Figma staff reply on the forum confirmed as intended a change that removes properties from layers wrapped into a slot. Figma flags it in the file with a “Properties removed from layers in this slot” message, so review wrapped layers before you publish.
FAQ About Figma Components Best Practices
When does an element deserve to become a component?
Once it appears twice. UX Collective’s rule is to convert anything used two or more times, because one edit then updates every copy.
One-off layouts stay as plain frames.
Which keyboard shortcuts speed up component work?
Four cover most of it: create component (Option+Command+K, or Ctrl+Alt+K on Windows), detach instance (Option+Command+B, or Ctrl+Alt+B), open the Assets panel (Option+2, or Alt+2), and duplicate a variant (Command+D, or Ctrl+D). Figma’s Help Center lists all four.
How do you audit a library for detached and unused components?
Library analytics, on Organization and Enterprise plans, shows how components and variants get used and how often instances are detached.
On a Professional plan, search the file with Command+F or Ctrl+F for the component’s layer names and review the hits by hand.
Where should component documentation live?
In the component description. It appears in the Assets tab when someone selects the component, and in the right sidebar for any instance.
A few sentences on usage and constraints is enough, and the field can hold a link to documentation hosted elsewhere. Dev Mode surfaces those links for developers too.
Keeping a Figma Component Library Healthy After Launch
Following Figma components best practices after launch means reading usage before changing anything, then retiring components on a schedule. Usage data decides how much testing a change needs, how early to announce it, and how long a deprecated component stays available.
Usage and detach rates come first. Additive changes get published before anything else, and a component gets deprecated before it gets removed.
Removal goes last because instances in consuming files depend on the component until the deprecation window closes.
The cost is a longer Assets panel. During the transition, the replacement sits beside the old component, which is the less disruptive path Figma recommends.
Recheck any slot-based design whenever Figma changes slot behavior, as it did in April 2026 (position verified October 27, 2026).
Governance beyond single components is the next step, and these design system best practices pick it up from there.
- How to Insert Image in Figma With Ease - November 3, 2026
- How to Download Figma Files Fast and Free - October 30, 2026
- Figma Keyboard Shortcuts That Will 10x Your Speed - October 25, 2026


