Instance

There was a time when changing a button color was a two-day job. Every new screen started by copying the button from the previous screen, so a file ended up holding forty identical buttons that had nothing to do with each other. Fixing one left the other thirty-nine untouched.

Pagedeck lived through this. The day Grace asked for a slightly deeper accent color, Noa opened the design file, paged through every screen, found each button, and re-applied the color by hand. It took two days and she missed three of them. The three missed buttons surfaced two weeks later during implementation, when Theo asked whether this one screen was supposed to have a different button color.

The problem was not that hands are slow. It was that the same shape had been stored separately in forty places, with nothing in the file saying which one was the reference. Anyone making a change had to find the rest from memory. So design tools flipped the arrangement: keep the original in exactly one place, and put copies that point back at it into the screens. Those pointing copies are instances.

Build one source component, drop a copy of it onto each screen, and every copy follows when you edit the source. A copy doesn't carry its own appearance — it carries an address that leads back to the original. There are four steps.

1. Make the source. Draw the button once, carefully, then register it as a component. The source usually sits in a housekeeping area outside the screens people will actually see.
2. Place it. Drag it out of the component list and an instance appears at that spot. Drag it onto forty screens and there is still exactly one source.
3. Override only the parts that differ. One spot says Save, another says Cancel. Values that have to vary per spot — text, icons, whether an element shows at all — can be changed on the instance itself, and those overrides survive later edits to the source.
4. Edit the source. Every property you didn't override changes across all forty. Move the corner radius from 4 to 8 and forty screens round off together, while the spot where you changed the label in step 3 keeps its label and takes the new radius.

The rule at that boundary is that visible content varies per spot while structure and dimensions stay with the source. Not being able to change button height on an instance is the design, not a limitation.

Breaking the link is also an option. Detach an instance and that spot becomes an ordinary group of shapes that no longer follows anything. It's for the one place that genuinely needs a shape the source doesn't have, but a detached spot quietly drops out of every future update. That is where most "one screen still looks like it did six months ago" stories come from.

Instances appear wherever a collection of components meets the screens that use them. Three places in particular.

1. Design work. In a tool like Figma, where several people edit the same file, buttons and inputs are not redrawn — they are pulled out of the component list. Making a screen shifts from drawing to choosing.
2. Sharing components. When a team keeps a component library, a file holding the interface parts built once and stored together, the sources live there and only instances come into each working file. Fix a button in the library and every working file gets an update notice; whether to accept it is up to whoever owns that file. Release timing stays on the source side.
3. Handing work to engineering. During design handoff, the process of passing a design to the people who will build it, a developer's first question about any element is whether it's an instance or a shape someone drew. An instance maps onto a component that already exists in code. A detached shape means asking why it has to differ.

The share of elements that are instances also measures whether a design system is actually in use. If 90 of the 120 buttons across the screens are instances and 30 are hand-drawn, those 30 are places where the system didn't cover the need or where a deadline won. The cleanup those 30 represent is called design debt.

"This is an instance, right? If it's detached we have to build the button from scratch."

Connected to the source means reusing the component already in code; detached means one more item of implementation work.

"Once you accept the library update, button height changes to 40."

The source changed, so the instances in everyone's files need to take the update.

"This is the only detached one. Do you remember why?"

Asking whether the one spot that won't follow the source had a real reason behind it.

A day of Noa's work on the pricing screen goes like this. She drags a button out of the library and changes nothing but the label, to "Start free." A few days later Grace asks for a deeper accent color, so Noa edits the one source and publishes the library. The next morning Theo opens his file, sees the update notice, and the moment he accepts it forty screens of buttons turn the new color at once.

What stands out that day is whatever didn't follow. Noa looks into the one button still sitting in the old color and finds it was detached last month under deadline pressure. If that shape turns out to be worth keeping she adds it to the source and reattaches the spot; if it was a one-off, she swaps the source version back in.

People often say an instance can't be touched, so you have to detach it before you can change anything. Given the description — it follows the source — that's a reasonable guess. In practice text, icons, and visibility can all be changed right on the instance, and those overrides survive updates to the source. Detaching over a single line of text costs that spot every future update, and on the day a color or a height changes it is the one screen left in the old shape.

The other common belief is that an instance amounts to a copy and paste. On screen the two are indistinguishable, and both take about the same effort to place, so the distinction looks academic. It shows up the first time something changes. Forty instances take one edit; forty copies take forty. A file built on copies gets more expensive to change as it grows, until nobody wants to answer a request as small as changing one color.