Figma Components & Variants Explained

A Figma component is a reusable, master version of a design element — a button, a card, a nav bar — that you can place anywhere in a file as an instance, and updating the master updates every instance automatically. A variant is a way of grouping several related components (say, a button in its default, hover, and disabled states) into one set so they show up as a single component with a property switcher, instead of as separate unrelated pieces. Together they are the backbone of any Figma UI kit that is meant to be handed to a merchant or a developer and actually used, not just admired.

This matters more than it sounds like it should. A Shopify or e-commerce UI kit built without proper components and variants looks fine in a screenshot, but falls apart the moment someone tries to reuse it — every button has to be redrawn by hand, every state has to be recreated, and small inconsistencies creep in across pages. Our own Figma theme catalog is built around disciplined component and variant structure specifically so that customizing a page doesn't mean rebuilding it. This tutorial walks through what components and variants actually are, how to build them well, and the mistakes that turn a promising design system into a maintenance headache.

What a Component Actually Is

Think of a component as a template with a live connection back to its source. When you select an element in Figma and choose Create Component, Figma turns it into a main component — marked with a purple diamond icon — and any copy you drag out of the assets panel becomes an instance of that main component, marked with a hollow purple diamond. The instance looks identical to the main component at first, but it isn't a static copy: it stays linked. Change the fill color, padding, or text in the main component, and every instance in every file that uses it updates to match, without you touching each one individually.

This is the entire point of componentizing a design. Without it, a "reusable" button is really just a group or frame that gets copy-pasted around a file. It looks the same today, but the moment you need to nudge its corner radius or swap an icon, you are hunting through every page to fix each copy by hand — and inevitably missing one. Components turn that manual, error-prone process into a single edit.

Instances can still be customized

A common misconception is that instances are locked and can't be changed at all. In practice, an instance can still have its own text content, its own icon swap, or its own color override — those are called overrides. What an instance can't do is drift from the main component's underlying structure (its layers, its base styling, its layout rules) without you detaching it entirely. Overrides let a single button component serve dozens of different labels across a storefront while still inheriting every structural update from the source.

What a Variant Adds on Top

Variants solve a different problem: what happens when one UI element naturally has several states or styles that all belong together conceptually. A button, for example, might need a primary and secondary style, each with default, hover, and disabled states. Before variants existed, a designer would build six entirely separate components — Button Primary Default, Button Primary Hover, Button Secondary Disabled, and so on — with no structural relationship between them in the interface at all, even though they were clearly the same element in different clothes.

A variant set groups those six components into one, presenting them as a single component in the assets panel with dropdown properties — Type: Primary/Secondary, State: Default/Hover/Disabled — that a designer picks from the right-hand panel instead of hunting for the correctly named layer. Behind the scenes, Figma still keeps each combination as its own component; the variant set is really an organizational and interaction layer on top, built by selecting a group of related components and choosing Combine as Variants.

Why this changes how a design file feels to use

The practical benefit shows up the moment someone other than the original designer opens the file. Instead of scrolling through a long, loosely-named list of components hoping to find the right button state, they select one instance and flip a property in the panel. It reads closer to using a real product's settings than digging through raw design assets, which is exactly the experience a merchant evaluating a theme, or a developer handing off implementation, needs.

Building a Variant Set, Step by Step

1. Design each state as its own component first. Build the default, hover, and disabled versions of the element fully, matching sizing and layer names across all of them — consistent layer names inside each variant matter more than almost anything else, since mismatched names cause awkward jumps when switching properties later.
2. Align them on the canvas and select all of them. Figma expects the set of components you're about to combine to be selected together; a tidy grid layout also makes the resulting variant set easier to scan later.
3. Choose Combine as Variants from the right-click menu or the toolbar. Figma wraps the selected components in a single variant frame and adds the property rows (Type, State, Size, or whatever dimensions you're varying) automatically, inferring names from your original component names where it can.
4. Rename the properties and values clearly. Figma's auto-detected names are a starting point, not a finished product — rename ambiguous ones like Property 1 to something a teammate would understand without opening the file's history.
5. Test by dragging out an instance and switching every property. Confirm nothing snaps, resizes unexpectedly, or reveals a layer that was named inconsistently in one of the source components.

Common Mistakes That Undermine a Component System

Inconsistent layer naming across variants

If the label layer inside your default button is named Label but the same layer inside the hover version is named Text, switching the State property will visually jump or reset unrelated overrides, because Figma matches overrides by layer name. This is the single most common reason a variant set feels "buggy" even though nothing is technically broken — it's almost always a naming mismatch between variants.

Too many properties on one variant set

It's tempting to combine every possible dimension — type, size, state, icon-or-not, alignment — into a single mega variant set. In practice this produces a combinatorial explosion of variants (four properties with three options each is already 81 combinations) that becomes slow to scroll through and hard to reason about. A cleaner pattern is to keep a variant set focused on two or three properties that genuinely change together, and use component props or separate components for dimensions that are more independent, such as icon placement.

Detaching instances instead of fixing the source

When an instance doesn't look quite right, it's faster in the moment to detach it and edit it directly — but that instance permanently loses its link back to the main component. Do this enough times across a file and you end up with dozens of near-identical, disconnected elements that all need to be fixed by hand again the next time something changes. If an instance consistently needs an adjustment the component doesn't support, that's a signal to update the main component or add a new variant, not to detach.

Building components without a token or style foundation

Components built on hard-coded colors and font sizes instead of shared color and text styles will drift the moment a brand color changes, because each component's fill has to be updated individually even though the component structure itself is shared. Pairing components and variants with a small set of shared styles (or Figma variables, where the plan supports them) is what actually makes a rebrand or a palette swap a five-minute job instead of a file-wide hunt.

How This Shows Up in a Real Storefront UI Kit

This is not an abstract exercise for us — it's the structure our Figma themes are built around. Our Wosa Figma theme and Medical Figma theme, for instance, ship product cards, buttons, badges, and form fields as variant sets rather than one-off frames, so a merchant or designer customizing the file can swap a button's state or a card's layout from the properties panel instead of redrawing anything. For teams working across more than one storefront category, the multi-niche Figma bundle carries the same component discipline across every included theme, which keeps the hand-off to development consistent no matter which niche kit is in use.

If you're evaluating a Figma theme — ours or anyone else's — before you buy, it's worth opening the assets panel and checking exactly this: are buttons, inputs, and cards structured as variant sets with sensible properties, or are they a flat list of similarly-named frames? That single check tells you more about how pleasant the file will be to customize than any amount of visual polish in the cover image.

Frequently Asked Questions

What's the actual difference between a component and a variant?

A component is a single reusable master element with linked instances. A variant is a way of bundling several related components — usually different states or styles of the same element — into one switchable set so they behave like one component in the UI instead of several disconnected ones.

Can I add a variant to a set after it's already been created?

Yes. Duplicate an existing variant inside the set, adjust it into the new state or style you need, and Figma will add it as a new option under the relevant property automatically, as long as its layer names match the rest of the set.

Do I need Figma variables to use components and variants well?

No — components and variants work independently of variables and predate them in Figma. Variables (and even simple shared color/text styles) make maintaining a component system easier, since a single style update can cascade across every component built on it, but they are not a prerequisite for building a solid variant set.

Why does switching a variant sometimes reset my text edits?

This almost always comes down to layer naming. Figma preserves overrides on an instance by matching layer names between variants; if the equivalent layer in the variant you're switching to has a different name, Figma can't carry the override forward and it resets. Keeping layer names identical across every variant in a set is the fix.