Get in touch.

Thanks for reaching out! I'll be in touch soon.
Yikes! Looks like the form is busted. Check back later, or try getting in touch with me on twitter

When you should use variants VS creating separate components

Alice threw this one into the void on
January 23, 2022

Before variants, the only way we could organize Figma components was using forward slashes or frames to group and nest them together. This was fine, but it wasn't great. It forced us into very rigid folder systems.

Folks often asked, "what's the best way to order of the groups?" Figma's documentation has an example with the following hierarchy: , but does it make a difference to order it in that particular way? What if it was flipped? To me, the slash naming was absolutely necessary and helpful for organizing components, but hard to work with. Of all the combinations I tried, I was never happy with the group orders I came up with. Some were too convoluted, others were too loose. Finding that happy medium seemed impossible.

Then Figma introduced their variants feature in late October of 2020. Not only was it a game changer for the experience of modifying instances in mockups and prototypes, it also gave us a new, powerful way to organize components: variants let us flatten the structures that slash naming forced us into. Variants allow all a component's, well, variations, to be accessed in any order. You don't have to drill through a half dozen groups just to turn on dark mode!

But variants haven't made slash naming obsolete. Nor were they meant to! You can still use both to organize your components. But now that we have these two ways to organize and group components... when do you organize components using variants, and when do you use frames or slash naming? Are certain components better suited for slash naming than variants? When do you reach for one method over the other? Are there circumstances where slash naming still has an edge over variants?


Always use variants for:

Interactive states (e.g. default, hover, active)

Figma had to release variants in order to release their interactive components feature. Variants were were born to handle interactive states like hover, active, and focus. Without a doubt, you should always, always, always reach for variants when componentizing interactive states.

State of ability (e.g. default, disabled)

Some folks choose to lump this in with interactive state, but I personally think it makes more sense a distinct property. Another gain that comes with separating state of ability from state of interaction is that you can often present state of ability as a toggle switch!

Things you could use variants OR separate components for!

For everything in this section you should consider the following to help you choose between variants or separate components:

Resizing rules (e.g. hug, fixed, fill)

Sometimes you need to adjust some of the auto layout resizing rules on a handful of layers in a component. Sure, you can do this with overrides on the instance, but if you're not intimately familiar with the structure of the component this can become a fiddly, time consuming task. An example where this might come up is button components. Sometimes a button needs to hug its label and icon, but other times fill all available horizontal space. If you're using base components to help manage your button, there can be lots of adjustments to make to the nested layers in the instance.

Hierarchy (e.g. primary, secondary, tertiary)

Most folks might opt to handle hierarchy as a variant property. That's cool! But if you're worried about a component's number of variants piling up, you might consider handling hierarchy as a separate component. Buttons usually have a "hierarchy" property, but they're not the only components where this comes up! Hierarchy can apply to bigger chunks of interface too, like pricing comparison cards!'s offers two different packages: Essential, and Justuno Plus. Justuno Plus is the card that is higher in hierarchy compared to its neighbor to the left. The main structural difference between the two is that Justuno Plus has a list of offerings instead of a "website visitors" input and "annual or monthly" payment toggle. In cases like this, where there is a change in layer structure and difference in hierarchy, you may want to think twice before making a "hierarchy" property! That set up would absolutely work here, but keeping these as separate components would also make sense too.'s pricing cards

Size (e.g. small, medium, large, etc.)

Size as in t-shirt sizes, not devices or breakpoints! You might have a "small" card with 8px padding on all sides, and a "large" card that instead has 42px padding. Depending on the component, handling "size" with variants might be a no-brainer, but with others you might decide component swapping is the better option.

Validation (e.g. default, success, error)

Form elements are probably the first thing that came to mind for you when you think about validation. These guys are notorious for inflating the total variant count. Like buttons, form elements are richly interactive pieces of interface, but unlike buttons they can have tons of atom-sized objects hanging off of them: helper text, character count, icons with tooltips, labels with icons, icons that precede the input box, icons that trail after the input box... now multiply all of that on top of interactive states, states of ability, and sometimes resizing rules 🥵 whew! Form elements are a great example of components where the total variant count is at risk of running too high because of needing to support so many changes in the layer structure from variant to variant. This is where you really want to put usage under a microscope. What do your designers really need from this component?

My personal experience on the design teams I've worked on is that designers don't often use validation styling in their mocks or prototypes. We have those components primarily for documentation purposes. If you also find this is the case for you and your team, consider demoting validation styles from being a variant property to separate components. An example being .

Composition (e.g. product card in website search results vs product card featured in an article)

This is a big one. You might have a single component that requires very different layer compositions. Sometimes those compositions might be context dependent, like how Wirecutter displays products on their site. The page or section that a product is shown in changes what information about the product is displayed. Here are three examples:

On the home page there is a "Deals" column. Recommended products that have recently experienced a drop in price will appear here. It's a small space, so there's not a lot of room for detailed information. The photo, product name, price, seller, and savings is all that fits.

If you proceed to Wirecutter's Deals page, you'll find products are contained within cards and have a lot more information in them! Here we have detailed explanations about why Wirecutter recommends this particular product, along with the article this product is featured in, and a timestamp of when the deal had dropped.

Products also get featured in cards in Wirecutter's articles. This is where the card design gets fancier: there's a blue banner at the top left, and a small beak on the bottom left. The description in the card is shorter here than on the Deals page because  the editorial content is handled by the article. Instead, cards on article pages contain more interactive components like buttons and a bookmark icon. The orientation has changed too; the product image sits to the left of the buttons and description instead of above.

It could easily be argued these are all the same component: a product card. And because of that you might think it makes sense to handle them as variants in a single component named "product card." You could! That's a logical path to follow. But their visual and structural differences are unique enough that I'd recommend handling these as separate components with their own variants. Here's how I would build, organize, and name these components:

Here's a link to the community file for the Figma file above. The blue ribbon on that "article feature" product card was a puzzle to put together! But it's up and running with auto layout!

Changes in auto layout direction.

Auto layout direction is one of the few things Figma does not allow us to override on component instances. An example of where this might come up is when a layout needs to shift to accommodate new or different content.

Always use separate components for:

Different components (e.g. header vs footer vs button vs card)

For example, no one would combine their nav and footer as variants in a component named "global stuff"). They're separate chunks of interface that do different jobs, therefore they ought to be separate Figma components.

Icons that go by different names (e.g. gear VS house)

Bonnie Kate Wolf wrote a massively helpful piece for titled "A complete guide to iconography." You should bookmark this one. There's not a publication date on the article, but I'm pretty confident it was written before Figma introduced their variants feature, because she describes only using slash naming, frames, and pages to organize icon components, despite using the word "variant" four times in the article (kinda funny, it's like she predicted the feature name)! She has some great advice on naming components:

"a stopwatch icon should be named stopwatch, not speed. A lightbulb should be called lightbulb, not idea. You want to make instantly clear to people what the icon is, not what it communicates on a more conceptual level. Shorter names are better, too. When you need multiple words, use a dash to separate them."

But besides proper names, this is where you want to stick with separate components for each unique icon. Put another way, don't make one big "icon" component that has a property named "name" or "icon" with variants like "lightbulb", and "stopwatch" in it. Why? Because no one wants to open a mile long drop-list to switch from one icon to another. Swapping one icon component for another is much easier.

Foundational atoms and molecules with unique HTML tags

This is more a guideline than a hard and fast rule, and I believe it helps reduce risk of things getting lost in translation between designers and engineers. Eventually, engineers are going to be referencing your Figma components so they can build the product in real life. As much as we can align our Figma components to the structures of the real web, built on HTML, the less translation work we create for our developer colleagues.

HTML tags I try to watch out for include:

Placeholder or "slot" components

These components allow you to "edit" an instance's layers without detaching. If you haven't heard about these bad boys, watch Adam Przewoski's youtube tutorial about them.

Base components

Similar to placeholder components, base components have to be separate components. If you're looking to super charge your component management workflow, read this article by Carol Chan.

Starter-kit components

Starter-kits are meant to be detached, so naturally you want them to be their own components. Not familiar with how a starter kit can save you time putting together mockups and prototypes? Read about starter-kits here!

BONUS: Things you might consider organizing at the library level

The question so far as been "when should you use variants, and when should you make separate components", and that's all been in the context of a single Figma library file... but there's a third option: separate components, in separate libraries.

Why do this? Well, if you're familiar with swapping components and the benefits that offers, take that same concept and apply it to libraries. Figma's help doc on library swapping has three examples where library swapping is handy:

Take Netflix for example: their design team works out of many different component libraries to produce both the app we enjoy. That app needs to work on your TV, on your phone and tablet, and in your browser. Instead of working out of one big library and handling "device" as a variant property, or even as separate components, they chose (wisely, I think) to handle device at the library level.

Another choice they made that helps keep the Netflix app experience uniform across those three very different devices is underpinning their device-specific libraries with a library called "Foundations." My understanding of their Foundations library is that it feeds components and styles into their device specific libraries. Overrides might get made to those Foundations components to account for device specific needs (text on the TV is likely much bigger than mobile devices), but this is what helps create that cohesive Netflix experience.

Annotated screenshot from the Netflix team's Schema 2021 talk
Annotated screenshot from the Netflix team's Schema 2021 talk

That's just one way to do it though. Your team might have different needs. Maybe your team only designs for mobile, but offer four different color themes... you could handle that with separate libraries!

Breakpoint/Device (e.g. mobile, tablet, desktop).

This is one that is truly dependent on how you/your team works and what experiences your product offers. Some product organizations have entirely separate teams of designers working on desktop and mobile experiences, and they might maintain separate libraries. Or everyone could be merged together, with all designers expected to mock up, prototype, and spec out experiences across all devices. Netflix's designers warn against structuring your design system off of your team structure:

"One trap we should all avoid is coming up with a design system that is shaped around a team, because a team could very well change. Instead a design system should be here to stay." Luca Orio - Schema 2021

Style (e.g. filled VS stroke)

Coming back to Wolf's article  Remember, this was very likely to have been published pre-variants: when it comes to different styles of the same component (in this case, icons), she says:

"When you have the same icon with variants, here's how I like to handle them...
Filled vs. stroked: If you are using both styles, use a slash after the icon name to indicate filled or stroked icons."

Like breakpoint, I think whether you handle the "style" of a component as a variant, as separate components or in a different library altogether depends on your needs and the need of the product you're designing for. Talk this one out with your team!

Theme (e.g. dark mode)

Figma's library swapping feature was made with this in mind. Similarly to how variants were made to support interactive components, library swapping was made to support theming. Because of this, I have a bias toward using libraries to handle theming.

Adjusted imagery

In that same iconography guide by Wolf, she talks about "adjusted imagery" with the example of a shield icon that has different currency glyphs or symbols in them:

"Adjusted imagery: When you have an icon with a visual variant (for example, multiple currency variants), you can also use naming to help differentiate, using the same method as filled vs stroked icons."

Like style, and like breakpoint, you and your teammates should discuss what organizing tool you want to reach for.

There are two big takeaways from all this:

  1. There are a many ways to peel a potato. Some folks will build button components with a "size" property, and others will use separate components with slash naming or pages for managing size. Both work. Neither is objectively better. As long as the people using the component think the structure and organization schema make sense and it helps them do their jobs, that's all that matters. Figma components are tiny products. Make them usable.
  2. If you're building components that other people are using, they should be included in conversations about how to build and structure components.

Interested in more?
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.