In a design system, what does a rising rate of detached or overridden component instances tell the system team, and how should it respond?
answer
- a demand signal, not a crime
- which component, which property, which team
- exploration files versus shipping files
- missing variant, wrong default, or bug
- fix the system, then re-measure
basics
~20 sA rising detach or override rate means the system no longer fits a real need: a missing variant, a wrong default, a bug or unclear guidance. Segment it by component and cause, ask the teams, fix the system, re-measure.
solid answer
~40 sA **detached instance** is a design-file copy whose link to the shared library component was broken, so it no longer receives library updates; an **overridden instance** in code keeps the reference but changes its styling or behaviour. Both are consumers voting with their feet. A rising rate is a demand signal, not proof of carelessness. I'd segment it: which components, which properties are changed, which teams and which files, separating exploratory design files from ones headed to production. Then I'd talk to the teams to find the cause: a missing variant, a default that fits nobody, a bug, or guidance they never found. The response depends on the cause: add or change the variant, fix the bug, or improve the docs. Finally I re-measure the same segment to confirm the rate falls.
go deeper
Recall what detaching an instance does, that it stops library updates reaching it, and that a detach usually means the component did not fit a need.
Explain the design-file and code forms of the signal, and the usual causes: missing variant, wrong default, defect, docs gap or exploration.
Show how you would segment a rising rate by component, property, team and file status, find the cause with the teams, fix the system and re-measure.
Weigh when to lock components against letting teams diverge, and how to use detach data without turning it into blame that drives work out of the system.
## Detached and overridden instances In a **design system**, consumers use shared components as **instances**: references to one master definition, so a fix to the master flows to every instance. - In a **design editor**, a designer can **detach** an instance, turning it into a free-standing copy. It can then be edited without limit, but it no longer receives library updates. - In **code**, an engineer can keep the system component but **override** it: pass style overrides, wrap it in local styling, or replace part of its behaviour. The reference survives; the system's look or behaviour may not. Both are measurable. Design-library analytics commonly report detaches per component; a code usage scan can record style overrides per instance. As adoption metrics, they answer a question usage counts cannot: where does the system fail to fit the work people are doing? ## What a rising rate usually means A rising rate is a **demand signal**. Typical causes: - **A missing variant**: the product needs a compact size, an icon-only form or a new status colour, and the component does not offer it. - **A default that fits nobody**: most instances change the same property the same way. - **A defect**: a layout bug, an accessibility gap, or a behaviour that breaks in one context, worked around locally. - **Guidance nobody found**: the variant exists but the docs do not surface it. - **Legitimate exploration**: designers detach to sketch ideas that may never ship. Only the last is harmless by design. Careless use exists too, but it is rarely what drives a sudden, concentrated rise. Treating every detach as misuse misreads the signal and damages the relationship with consuming teams. ## Segmenting the signal | Cut | What it reveals | |---|---| | **By component** | Whether one component drives the rise, which points to a gap in it | | **By changed property** | Whether people change size, colour, spacing or content, which names the missing variant | | **By team or product** | Whether one product has needs the system does not know about | | **By file status** | Whether the detaches sit in exploration files or in files headed to production | | **Over time** | Whether the rise started with a particular system release | A rise that starts right after a release often means the release changed something consumers depended on. ## Responding 1. **Segment** the rate as above until it names components and properties. 2. **Ask the teams** involved what they needed; a short conversation beats a week of guessing from numbers. 3. **Classify the cause**: missing variant, wrong default, defect, docs gap or exploration. 4. **Act on the system**: add the variant, change the default, fix the defect, or rewrite the guidance so the existing option is findable. 5. **Re-measure** the same segment after the change ships, and confirm the rate falls. In a customer-support ticketing tool, for instance, a spike in detached status badges may come from the escalations team, which needs an extra 'waiting on customer' status the system's badge does not allow. The fix is a status variant, not a reminder email about detaching. ## What not to do - Set a **zero-detach target**: teams will stop detaching in files you measure and hand-build instead, which is worse and invisible. - **Publicly rank teams** by detach rate, which turns a signal into blame and suppresses honest usage. - **Lock components** so they cannot be detached or overridden at all, before the system covers the real needs; teams will leave the system rather than wait. - Count exploration files the same as production files, which makes a healthy design process look like drift. ## Why this matters for adoption The detach and override rate is the adoption metric closest to the consumer's lived experience. Usage and coverage say how much of the product the system supplies; the detach rate says where it is losing that share, and why. A system team that reads it as a product backlog keeps its consumers; one that reads it as a compliance problem loses them.
- Why is a zero-detach target counterproductive?Detaching is visible and measurable; hand-building a local copy is not. If teams are judged on detaches, they will stop detaching and start drawing or coding their own parts, which removes them from the system and from the metrics at the same time. The target hides the need instead of meeting it.
- How do you tell a missing variant from careless use in override data?Look for repetition. When many instances across several teams change the same property the same way, it is a need the system does not meet. Scattered, one-off changes with no pattern are more likely careless use or exploration, and are better handled through guidance than through a system change.
It is like a footpath worn across a lawn beside a paved path: the worn track is not vandalism, it shows where people actually need to walk, and the fix is often to pave it.
saying these in an interview costs you the question
- Every detached instance means a designer ignored the system's rules.
- The right response is to lock components so they cannot be detached.
- A zero-detach target is the best way to improve adoption.
- Detaches in exploration files count the same as those in production files.
- The detach rate is only a design concern, with no code equivalent.