A smart-home app team shipped its thermostat screen on an experimental design-system dial, and a later system release broke it. How should the system show status so this does not recur?
answer
- where did the team meet the dial
- status at every point of use
- design files, docs, workshop, code
- know who depends on experiments
- warn before changing, not after
basics
~20 sShow status everywhere consumers meet the component - design library, docs, component workshop, its name or entry point in code, and development-time warnings - and track who uses experimental components so they are warned before a breaking change.
solid answer
~40 sThe failure is usually not the label's existence but its **visibility**: the team met the dial in a design file or a copied example, never on the docs page that said experimental. So I would put status at **every point of use**: a badge on the docs page and in the component workshop; the same marking on the asset in the design library, so designers do not spec experiments into production screens unknowingly; a **distinct name or entry point** in code; and a **warning in development builds**, never shown to end users. Then close the loop: **track which products use experimental components**, through dependency or usage scanning, and notify those teams before a breaking change lands. For teams that need an experiment in production, offer an explicit opt-in so the dependency is known.
go deeper
Recall that a maturity label only helps if consumers see it where they pick up the component: design files, docs, workshop and code.
Explain which surfaces carry status, why one vocabulary matters across design and code, and why warnings belong in development builds only.
Show how you would diagnose the invisible-status failure, add tracking of experimental usage, and give teams an explicit opt-in path without blaming or freezing.
Weigh how much tooling and process to invest in status visibility and usage tracking against the cost of broken product screens and lost consumer trust.
## What went wrong In a smart-home control app, a product team built the production thermostat screen on a design-system **thermostat dial** labelled **experimental**. A later system release reworked the dial's interface and visuals, and the screen broke. The system team followed its own rules: experimental components may change in any release. The product team says it never knew the dial was experimental. Both statements can be true. A **maturity label** only protects consumers if they see it **at the moment they decide to depend on the component**. Most teams meet a component in one of these places: - a **design file**, where a designer drags the asset from the shared design library into a mock-up; - an **example** or a neighbouring screen whose usage an engineer copies; - the **component workshop**, the interactive catalogue of rendered components; - the **documentation site**. If the status appears only on the docs page, three of the four routes skip it. ## Make status visible at every point of use | Surface | How status is shown | Who it reaches | |---|---|---| | Design library | stage in the asset's name or section, a visible marker on the asset | designers choosing components | | Documentation site | badge at the top of the page, with what the stage promises | anyone reading docs | | Component workshop | the same badge on every example | engineers browsing components | | Code | a distinct entry point or name for experimental components | every usage, including copied ones | | Development builds | a one-time warning when an experimental component renders | engineers running the app locally | | Release notes | changes grouped by stage | teams upgrading | Two rules make this work: 1. **One vocabulary everywhere**: the same stage names and meanings in design, docs, workshop and code, so the label means one thing. 2. **Warnings only where someone can act**: development-time warnings help engineers; showing them to the smart-home app's end users would be noise they cannot act on. ## Know who depends on experiments Visibility prevents accidental dependence; **tracking** handles deliberate dependence. The system team should know which products use each experimental component, for example by scanning consuming codebases or dependency manifests for the experimental entry point. With that list: - Before a breaking change to the dial, the system team contacts the teams that use it, rather than letting them find out from a broken screen. - High usage of an experimental component is a signal to prioritise its promotion. - Zero usage is a signal that the experiment may not be worth continuing. ## Offer a deliberate path into production Teams sometimes have good reasons to ship an experimental component. Rather than forbidding it, make it **explicit**: 1. The team opts in, for example by registering the dependency with the system team. 2. The team accepts that changes may need rework, and budgets for it. 3. The system team commits to warning them before breaking changes. That turns an invisible risk into a managed one. ## Status across platforms A system that ships to the web, to native mobile and to a design editor must show status on each of them, and the stage can differ per platform: the dial may be beta in the web library and experimental in the native one. The docs page should show the stage **per platform**, and each platform's library should carry its own marking, so a native mobile team is never reassured by a badge that only describes the web implementation. ## What not to do - **Blame the product team** for not reading the docs; if the status was invisible where they worked, the system's communication failed. - **Freeze the experimental component** to avoid breaking the one team using it; that turns it into an unacknowledged stable component and stalls the experiment. - **Show status warnings to end users**; they cannot act on them. - **Use different stage names in the design library and in code**, so designers and engineers disagree about what is safe. ## Measuring whether it worked Watch for experimental components appearing in production without a registered opt-in, and for support requests that begin 'we didn't know it was experimental'. Both should trend toward zero.
- Why should the design library show a component's maturity stage, not only the code and docs?Many product decisions are made in design files before an engineer is involved. If a designer places an experimental asset in a production mock-up without seeing its status, engineers build what was specified and the dependency is locked in early. Showing the stage in the design library stops that at the source.
- Why show experimental-status warnings in development builds but not to end users?The warning is for the people who can act on it - engineers deciding whether to depend on the component. End users of the smart-home app cannot change which components the product uses, so a warning would be confusing noise and would erode trust in the product itself.
saying these in an interview costs you the question
- A badge on the documentation page is enough to communicate a component's status.
- If a team depends on an experimental component, the system must freeze it.
- Consumers who miss a status label are solely responsible for the breakage.
- Status warnings should also be shown to the product's end users.
- Designers do not need to see maturity stages; only engineers choose components.