Components & variants

Components are the heart of scalable UI design — reusable elements you define once and use everywhere, so a change to the master updates every copy. Variants group a component's different versions (a button's primary/secondary/disabled states) into one tidy, switchable set. Together they're how you build UI systematically instead of redrawing the same button fifty times. Let's build reusable components.

Components — define once, reuse everywhere

COMPONENTS — reusable master elements.

- A MAIN (master) COMPONENT is the source definition of a UI element (a
  button, a card, an input, an icon).
- INSTANCES are copies you place throughout your designs. Each instance is
  LINKED to the main component.
- EDIT THE MAIN -> ALL INSTANCES UPDATE automatically. Change the button's
  corner radius on the master -> every button everywhere updates. This is
  the whole point.
- OVERRIDE per instance — you can change specific properties on an instance
  (its text, an icon, a colour) WITHOUT breaking the link. So instances
  share structure but can differ in content.

CREATE: select an element -> "Create component" (Ctrl/Cmd+Alt+K, or the
component icon). Place instances by copying it or dragging from Assets.

WHY: build a UI element ONCE, reuse it consistently, and maintain it in ONE
place. This is what makes design systems possible + keeps large products
consistent. Components turn "50 hand-drawn buttons" into "1 button, used 50
times".

The core idea: a component is defined once (the main) and reused as instances that all stay linked — edit the main, and every instance updates. Instances can override content (text, icon) without breaking the link, so they share structure while differing in content. This is what makes UI maintainable: one button, used everywhere, changed in one place.

Variants — organising a component's versions

VARIANTS — group related versions of a component into one set.

A component often has several versions:
- A button: Primary / Secondary / Ghost; Default / Hover / Pressed /
  Disabled; Small / Medium / Large; with icon / without.
Rather than separate components, combine them into a VARIANT SET with
PROPERTIES:
  - PROPERTY "Type": Primary | Secondary | Ghost
  - PROPERTY "State": Default | Hover | Disabled
  - PROPERTY "Size": S | M | L
  - BOOLEAN "Has icon": true | false

Now an instance is configured via simple DROPDOWNS/toggles in the right
panel (pick Type=Secondary, State=Hover, Size=M) — instead of hunting for
the right component. One tidy, switchable component covers all combinations.

CREATE: select the versions -> "Combine as variants" -> name the properties.

BENEFIT: a clean, organised, easy-to-use component API. Designers pick the
version they need from dropdowns; the set stays maintainable. This mirrors
how real coded UI components take props.

Variants bundle a component's versions (type, state, size) into one switchable set with properties — so instead of hunting through fifty separate button components, a designer picks "Type: Secondary, State: Hover, Size: M" from dropdowns. This creates a clean component API that mirrors how real coded components take props, and keeps the whole set organised and maintainable.

The mistake beginners make

The productivity-destroying mistake is not using components — copying and pasting elements instead — so the same button exists as fifty independent copies, and changing the design means editing all fifty by hand (and missing some). Make it a component once; update it in one place. The second mistake is a chaotic mess of separate components for every version (button-primary, button-primary-hover, button-secondary-small...) instead of variants — making the library impossible to navigate. Combine versions into variant sets with clear properties. The third mistake is detaching instances or over-overriding — breaking the link to the main component (losing the update benefit) or overriding so heavily that instances no longer match the system. Keep instances linked, override only content. Components not copies, variants not chaos, instances stay linked — the foundation of a real design system.

Your turn

---

Your turn

1. Create a component: design a button (with auto-layout), then select it and Create Component (Ctrl/Cmd+Alt+K). Place several instances around your canvas.
2. Test the superpower: edit the MAIN component (change its corner radius or colour) and watch every instance update automatically. Then override just the TEXT on one instance — notice it stays linked.
3. Build variants: create Primary, Secondary, and Ghost versions of your button, select them, and 'Combine as variants'. Name the property 'Type'.
4. Add more properties: add a 'State' property (Default/Hover/Disabled) and a 'Size' property (S/M/L). Now configure an instance via the dropdowns in the right panel.
5. Compare with the wrong way: copy-paste a plain button 5 times, change the design on the master idea, and realise you'd have to edit all 5 by hand — then appreciate why components win.

Key points

• Components are reusable master elements defined once: a MAIN component with linked INSTANCES — edit the main and all instances update automatically, while instances can override content (text/icon) without breaking the link.
• Components make UI maintainable — build an element once, reuse it consistently, change it in one place ('50 hand-drawn buttons' becomes '1 button used 50 times') — the foundation of design systems.
• Variants group a component's versions (Type, State, Size, has-icon) into ONE switchable set with properties — configured via dropdowns/toggles, creating a clean component API that mirrors real coded components taking props.
• Create a component with Ctrl/Cmd+Alt+K, place instances from Assets, and 'Combine as variants' to bundle versions with named properties.
• The mistakes: copy-pasting instead of using components (must edit every copy by hand), a chaotic mess of separate components instead of variants, and detaching/over-overriding instances (breaking the link) — components not copies, variants not chaos, instances stay linked.