Components and variants — design once, reuse everywhere

Choose your track

Read this module through your lens

Copy-paste is a debt

In the first courses you built screens by placing and duplicating elements. That works until the product grows. The moment you have the same button on forty screens, you have forty independent things that happen to look alike — and the day the brand colour or corner radius changes, you must find and fix all forty by hand. You will miss some. The product drifts into quiet inconsistency, and every change gets more expensive.

This is the wall every self-taught designer hits, and the way through it is the single most important idea in design systems: stop copying, start componentising. A component lets you define a thing once and reuse it everywhere with a live link, so a change in one place propagates everywhere. It is the difference between drawing the same button forty times and building one button used forty times.

This is also where design starts to resemble engineering — define once, reuse, change in one place — which is exactly why design systems and codebases mirror each other.

Masters and instances

The model has two roles. A component is the master definition — the canonical button, made once and made well. An instance is a linked copy you place wherever you need the button. Instances stay connected to the master: edit the master’s colour, padding, or radius, and every instance updates instantly, across every screen and file that uses it.

You create a component by selecting a well-built element and choosing Create component (Cmd/Ctrl + Alt + K). From then on, copies are instances, shown with a diamond marker. The discipline is simple but strict: edit the master to change the design; on instances, only override content (the label text, the icon), never the structure. The moment you start restructuring an instance, it drifts from the master and you have re-created the copy-paste problem with extra steps. Detaching an instance — severing the link — should be rare and deliberate.

Variants collapse the states

Real components are not single pictures; they have states. A button is default, hover, pressed, disabled, loading. Modelling each as a separate component would scatter them. Variants solve this: you combine the related states into one component and add a property — say State, with values default / hover / disabled — that you switch from a dropdown in the properties panel.

This does two powerful things. It keeps all the states of one thing together as a single switchable unit, so a designer picks “the button” and then chooses its state. And because the variants share identically named layers, they cooperate beautifully with Smart Animate from the last course — switching a variant can tween, giving you state transitions almost for free.

Watch the failure modes: variants with mismatched layer names break both switching and animation, and a single mega-component crammed with dozens of unrelated variants becomes unusable. Keep a component focused on one thing and its genuine states.

Hands-on exercise

Take a button you built earlier and make it a component. Build at least two states (default and hover, or default and disabled) and combine them as variants with a State property. Place several instances across a screen, then edit the master — change its colour or radius — and confirm every instance updates. Give one instance a different label to prove content override works while style still tracks the master. Note how much faster a brand change just became.

Second case · an icon button set

The same lesson, a different object

Common failures · spot them fast

The failure gallery

Each of these is caught by a quality gate — keep the cheatsheet open while you work.

Worked example

Watch the journey

Cheatsheet

Reflection