In a design system, why must a shared component clear a stricter release bar than a feature built for one product screen?
answer
- one defect, many consumers
- consumers cannot patch inside it
- contexts the author never saw
- trust decides adoption
- fixing after release costs more
basics
~20 sA shared component's defects multiply: every consuming team inherits them, cannot easily fix them locally, and starts distrusting the system. So its bar covers every context consumers use - themes, locales, screen sizes, assistive technology - not just the first screen.
solid answer
~40 sA feature on one screen has one layout, one audience and one team that can fix it the same afternoon. A shared component is reused by many teams, on screens its authors never saw, in themes, locales and densities they may never test themselves. A defect therefore ships everywhere at once, and consumers usually cannot repair it inside the component: they wait for a release, override styles or fork, and each of those erodes the system. That is why **done** for a shared component means done for **every supported context** - accessibility, responsive behaviour, localisation, theming, docs, tests, design parity and sign-off. The extra effort is paid once by the system team instead of repeatedly by every consumer, and it is what earns the trust that drives adoption.
go deeper
Recall the core idea: a shared component is used by many teams in many contexts, so its defects multiply and consumers cannot fix them locally.
Explain the economics - verify a context once in the system versus many times in consumers - and name the contexts a checklist makes explicit: theme, locale, size, input and density.
Show you have seen the failure mode: overrides and forks spreading after a rushed release, and how you would restore trust while keeping the bar usable under deadline pressure.
Frame the bar as a promise that sustains adoption: how strict it is sets both the system team's throughput and consumers' willingness to depend on the system.
## Two meanings of 'done' A **release-readiness checklist** (also called a quality bar) is the set of conditions a shared component must meet before a design system publishes it for other teams to use. A product feature has a done-ness bar too, but it answers a narrower question: does this screen work for the people who use this screen? A **shared component** - a button, a date-range picker, a data table - answers a wider one: will this work on every screen, in every product, that is going to use it? That difference in audience is the whole reason the bars differ. The component's author typically builds it for one requesting team, on one screen, in one theme. The moment it is released, it will also be used by teams the author has never met. ## The multiplier A defect in feature code has a **blast radius** of one screen. A defect in a shared component has a blast radius of every place it is used. - **Reach**: if a B2B analytics dashboard, an admin console and a mobile companion app all use the same filter chip, a contrast bug in it ships to all three at the same time. - **Discovery cost**: each consuming team discovers the defect separately, often in their own QA or from their own users, so the same investigation happens several times. - **Workaround cost**: each team builds its own local fix, and later has to remove it when the system ships the real one. - **Trust cost**: after two or three such surprises, teams start copying the component into their own code so they control it. That is how a design system loses adoption. ## Consumers cannot fix what they do not own A product team owns its feature code and can change it immediately. A consuming team does **not** own the shared component. Their options when it breaks are all bad: 1. Wait for the system team to release a fix. 2. Override the component's styles or behaviour from outside, which is brittle and breaks on the next upgrade. 3. Fork it - copy the source into their product - which ends their relationship with the system for that component. Because those options are bad, the system has to catch problems **before** release, which is what the stricter bar does. ## Done for contexts you have not seen | Context | What the author usually tried | What consumers will do | |---|---|---| | Theme | the default light theme | dark, high-contrast, a second brand | | Locale | the source language | longer translations, right-to-left scripts, other date and number formats | | Size | one desktop width | narrow panels, tablets, phones, text enlarged by the user | | Input | a mouse | keyboard only, screen reader, touch, switch access | | Density | the default | compact tables, spacious touch layouts | The checklist exists to force each of these columns to be checked on purpose. Its usual items are accessibility conformance, responsive behaviour, localisation readiness, theme support, documentation, automated tests, parity with the design asset, and sign-off by design and engineering. The bar covers the contexts the system has **promised** to support, not every imaginable one. Anything the component deliberately does not support should be documented as a limit, so a consumer learns it from the docs rather than from production. ## Why the cost pays back The bar is extra work for the system team, and teams under deadline pressure often feel it as bureaucracy. The economics run the other way: 1. The system team verifies a context **once**; without the bar, every consumer verifies it separately or ships the defect. 2. A defect caught before release costs one change; a defect caught after costs a release, release notes, upgrades in every consumer, and removal of every workaround. 3. Predictable quality is the main reason teams choose a shared component over writing their own. The bar is how the system keeps that promise. ## Common misreadings - **'It works on the requesting screen, so it is done'** - that is the feature bar, not the shared-component bar. - **'Consumers can override it if it breaks'** - overrides are a symptom of a missed context, not a support strategy. - **'Accessibility can come later'** - retrofitting a keyboard model or accessible names after many teams depend on the component's structure is far harder than building it in, and the gap harms users in the meantime. - **'Stricter means slower forever'** - most items become routine and partly automated; the slow part is the first time a team learns what the bar asks.
- Does a stricter bar mean a shared component must support every possible context before release?No. It must support every context the design system has promised - its declared themes, locales, densities, sizes and input methods - and document anything it deliberately does not do. An unsupported context should be a written limit consumers can read, not a surprise they discover in production.
- Who actually pays when the bar is skipped to ship a shared component faster?The consumers pay, several times over: each team discovers the defect separately, builds a workaround, and later removes it after the fix ships. The system team pays in patch releases and support questions. The longer-term cost is trust: teams that were burned start keeping local copies, and adoption falls.
A shared component is like a standard part in a car factory: a flaw in one bolt design is not one faulty car, it is a recall of every model that uses that bolt.
saying these in an interview costs you the question
- A shared component is done when it works on the screen that requested it.
- Consumer style overrides are an acceptable substitute for theme support in the component.
- The release bar is bureaucracy that only slows the system team down.
- Accessibility can be added later, once consuming teams ask for it.
- Passing unit tests proves the component is ready for every consuming team.