Components, Variants & Instances

Figma

Chapter 5 · Components, Variants & Instances

Chapter 4's own tip box pointed here directly: a component depends on Auto Layout to resize correctly wherever it's reused. This chapter covers what a component actually is — a reusable master element, and the live-linked copies of it that make up most of a real design file.

What a Component Actually Is: A Reusable Master

A component is a designated "main" version of a reusable element — a button, a card, a navigation bar — defined once and reused throughout a design. This is the same underlying idea as a Slide Master in Word & PowerPoint or LibreOffice's own Master Slide: one master definition that every reused copy stays connected to, rather than independent, disconnected duplicates.

Instances: Live-Linked Copies

An instance is a copy of a component placed elsewhere in the design, staying live-linked back to its own main component rather than becoming an independent, disconnected duplicate the moment it's placed. A single button component might have dozens of instances scattered across many different screens in the same file, all pointing back to that one shared definition.

Propagating Changes: Editing the Main Component Updates Every Instance

Editing the main component — changing its color, its padding, its icon — automatically updates every instance of it throughout the entire file, instantly. This is the real payoff of the master/instance relationship: a single edit to one button's color, for instance, ripples out to every single button in the design without needing to find and update each one individually.

Overrides: Instance-Specific Differences That Survive an Update

An individual instance can still have its own specific differences — different label text, a swapped icon, a different fill color for one particular case — called overrides. These per-instance differences survive future updates to the main component, so changing the main button's overall padding doesn't wipe out an instance's own custom label text, letting shared structure and per-instance customization coexist.

Variants: Grouping Related Components Into One Switchable Set

Variants group several related components — a button's default, hover, and disabled states, for instance — into one single switchable component set, with a property (like "State") that switches between them. Rather than managing three entirely separate components for three button states, Variants keep them organized as one logical unit with a clean property to switch between.

Components in Penpot: The Same Master/Instance Model

Penpot uses the same main component/instance relationship, including change propagation and per-instance overrides, under closely matching terminology — another place where Penpot's own deliberate similarity to Figma (established back in Chapter 2) makes the underlying concept transfer directly between the two tools.

Concept	What it does
Main component	The single master definition every instance stays linked to
Instance	A live-linked copy of the main component, placed elsewhere
Override	An instance-specific difference that survives future main-component updates
Variant	A group of related components (e.g. button states) switchable via one property

Components are the building blocks of Chapter 6

A design system, covered in Chapter 6, is essentially an organized library of exactly these kinds of components (plus shared colors and text styles), reused consistently across an entire product rather than confined to a single file.

Editing an instance directly doesn't update the others — and detaching is permanent

It's tempting to edit a specific instance directly when a change is meant to apply everywhere, assuming it'll somehow propagate back to the main component. Only editing the main component itself propagates a change to every instance — editing an instance directly just creates a per-instance override on that one copy alone, per this chapter's own material. It's equally tempting to "detach" an instance to fully customize it, but detaching permanently severs its live link back to the main component — that instance no longer receives any future updates at all, a one-way action worth confirming is actually needed before using it.

Hands-On Exercises

Exercise 1

A designer wants every button across a 40-screen design file to change from blue to green, all at once. Using this chapter's own material, explain the correct way to do this.

📄 View solution

Exercise 2

A colleague edits one specific button instance directly, expecting the change to appear on every other button instance too, and is confused when it doesn't. Using this chapter's own warning box, explain what happened.

📄 View solution

Exercise 3

Explain, using this chapter's own material, how a button's default, hover, and disabled states are organized using Variants, and why this is preferable to three entirely separate components.

📄 View solution

Chapter 5 Quick Reference

A component is a reusable master element, the same underlying idea as a Slide Master or Master Slide
An instance stays live-linked to its main component — editing the main component updates every instance
Overrides let an instance keep its own specific differences even after the main component updates
Variants group related components (like button states) into one switchable set
Editing an instance directly only creates an override on that one copy; detaching permanently severs its live link