skip to content

In a design system's design library, what are overridden and detached component instances, and why do they cause drift between design and code?

level: juniorimportance: should knowfreq 42%

answer

  1. a link to the library
  2. content change versus style change
  3. cut link, no more updates
  4. a variant only one file has
  5. engineers rebuild what they see

basics

~20 s

An overridden instance keeps its link to the library component but changes some properties locally; a detached one cuts the link and becomes loose shapes. Style overrides and detachments stop following library updates and depict components that code does not have.

solid answer

~50 s

An **instance** is a placed copy of a library component that stays linked to it, so library updates flow in. An **override** changes a property on that one instance: content overrides — label text, an icon, a nested component swapped from the allowed set — are how components are meant to be used. Style overrides — a brighter fill, tighter padding, a smaller size — create a local variant that exists only in that file and stays pinned when the library changes. **Detaching** cuts the link entirely: the instance becomes plain shapes that never update again. Either way the design now shows something the coded library does not provide, so the engineer either rebuilds a lookalike (a fork in code) or uses the real component (and the screen no longer matches its design). A cluster of detachments is also a signal: the library is missing something designers need.

go deeper

for a junior

Recall the difference between an instance, an override and a detached copy, and which overrides are ordinary use: text, icons and allowed nested swaps.

for a middle

Explain why style overrides stay pinned while the rest updates, why detached copies never update, and how each shows up in code as a forked lookalike or an unexplained mismatch.

for a senior

Show how you would find overridden and detached instances across many files and read repeated detachments as a library gap to close rather than a rule to enforce.

for a principal

Weigh how much local freedom designers should have against the drift it creates, and how the system team's responsiveness to gaps determines how often people detach at all.

## Instances and the link that keeps them honest In a design editor, a design system's components live in a shared **library**. When a designer places one on a screen, the placed copy is an **instance**: it stays **linked** to the library's main component. Change the main component — a new corner radius, a corrected color — and every linked instance in every file picks up the change. That link is what lets design files keep describing the current system without anyone repainting screens by hand. Two things weaken the link: **overrides** and **detaching**. ## Overrides: expected versus drift An override changes one property on one instance while keeping the link. In the usual instance model, overridden properties stay pinned to their local value when the library updates, while the rest update normally. Whether an override is drift depends on *what* is overridden: | Override | Example in a warehouse scanner app | Drift? | |---|---|---| | Text content | The pick-list row shows this order's item name | No — this is how components are used | | Swapping an allowed nested component or icon | The status slot shows a damaged-item icon instead of the default | No, if the component offers the slot | | Color or fill | The scan button made a brighter green on one screen | Yes — a local variant code does not have | | Spacing or size | Stepper buttons shrunk so a long product name fits | Yes — and it may break the component's target size | | Hiding required parts | The row's bin-location line hidden to save space | Usually yes — the component's anatomy changed | A useful rule of thumb: **content overrides are use; style and structure overrides are redesign**, and redesigning a system component inside one product file is where drift starts. ## Detaching **Detaching** converts an instance into ordinary layers. It is the escape hatch when the component cannot do what the designer needs — an extra line of text in a pick-list row, a layout the component does not support. After detaching: - the shapes **no longer receive library updates**, so a later fix to the component never reaches this screen; - nothing in the file records which component it used to be, beyond a layer name someone may rename; - inspect views can only show raw values, because the named styles and component identity are gone. ## How each turns into drift in code The design file is only half the story. Drift becomes real when it reaches the product: 1. **The engineer rebuilds the lookalike.** The screen shows a row that is not quite the library row, so someone builds a local copy in code. The product now has a **forked component** that misses future library fixes. 2. **The engineer uses the library component anyway.** The shipped screen differs from its design, and every later comparison reports a mismatch nobody can explain. 3. **The library moves on.** A year later the main component is updated; the linked screens follow, the detached ones do not, and designers start designing new features against a mix of old and new. ## Detecting overridden and detached instances Most teams find them in three ways: - **File scans** — a script or editor plugin walks the design files and lists detached instances and style overrides per file and per component. - **Design review** — reviewers ask of any custom-looking element: is this an instance, and what is overridden? - **Parity audits** — comparing shipped screens to their designs surfaces the detachments that reached code. - **Engineering questions** — when an engineer asks which component a layer is, the answer is often that it is not one any more. ## Treating detachment as a signal A single detachment may be a shortcut. **The same component detached in the same way across many files is a message**: the library lacks a variant or a slot that real screens need. The productive response is to ask why and feed the answer back to the system team as a proposed variant, not simply to forbid detaching. Forbidding it without closing the gap only moves the workaround somewhere harder to see. The same reading applies across platforms. A design library usually serves the web and native mobile at once, so a row detached only in phone layouts often means the component lacks a compact arrangement one platform needs — a gap the system team can close once, for every product that ships to that platform.

  • If an overridden instance keeps its link, why is a style override still a problem?
    The overridden property stays pinned to the local value while the rest of the instance updates. If the library later corrects that color or spacing, this screen keeps the old one — and the engineer building it sees a value the coded component does not offer, so either the screen or the code ends up different from the other.
  • Designers across three teams keep detaching the pick-list row to add a bin-location line. What do you do?
    Treat it as a library gap, not a discipline problem. Confirm the need with the teams, propose an optional secondary line or slot for the row component, and once it ships in both the design library and code, replace the detached copies with instances. Then check whether code already forked the row, because the same gap usually produced a lookalike there too.

saying these in an interview costs you the question

  • Any override of a library instance counts as drift.
  • A detached instance still updates when the library component changes.
  • Detaching is harmless as long as the result looks identical today.
  • The fix for detaching is to forbid it, not to ask why it happens.
  • Engineers should rebuild whatever the design shows, even a detached lookalike.