In a design system, what may a consuming team rely on when a component is labelled experimental, beta, stable or deprecated?
answer
- a label is a promise
- may change versus will not break
- announced breaks during beta
- stable breaks only in a major release
- deprecated names its replacement
basics
~20 sExperimental may change or disappear without notice. Beta is settling, with breaking changes announced ahead. Stable changes incompatibly only in a major release. Deprecated still works but gains nothing new and names its replacement and removal plan.
solid answer
~40 sA maturity label is a **promise about change**, and each stage promises something different. **Experimental** means the component may change shape or be removed in any release; use it to learn, not in critical flows. **Beta** means the design and API are mostly settled, it is safe to try in production with care, and breaking changes are possible but announced ahead. **Stable** means the component has cleared the full release bar, is supported, and will not change incompatibly except in a major release with migration guidance. **Deprecated** means it still works and receives critical fixes but no new features, and the docs name its replacement and planned removal. The exact names and rules are conventions each system publishes; what matters is that consumers can read the promise and plan around it.
go deeper
Recall the four common stages and, for each, what you may rely on: can it change, will breaks be announced, is it supported, is there a replacement.
Explain why the label is a promise about change and support, and how stages map onto a versioned package's compatibility guarantee.
Show how you would advise product teams choosing components by stage for real screens, including when accepting experimental risk is justified and how to signal that dependency.
Consider how many stages the system should offer and what it promises at each, trading speed of experimentation against the trust that makes consumers adopt stable components.
## What a maturity label is A **maturity stage** (or lifecycle status) is a label a design system attaches to each component to say how far along it is and, more importantly, **what consumers can depend on**. A design system is used by many product teams; each needs to decide whether it is safe to build a screen on a component. The label answers that question without every team having to ask the system team. The common set of stages is **experimental, beta, stable and deprecated**. The names and exact rules are conventions, not a standard: some systems say alpha, preview or candidate, some add a legacy stage, some use only two. What they share is the idea that stability is **declared**, not guessed. ## The four common stages | Stage | What it means | API and visual stability | Support | Sensible use | |---|---|---|---|---| | Experimental | an idea being tried with a few teams | may change or be removed in any release | best effort | prototypes, pilots, non-critical screens | | Beta | design and API mostly settled, gathering feedback | breaking changes possible but announced ahead | fixes prioritised | production with care and a plan to upgrade | | Stable | cleared the release bar, used across products | incompatible changes only in a major release, with migration guidance | full support | anything, including critical flows | | Deprecated | superseded or no longer recommended | keeps working until removal | critical fixes only | existing uses while migrating; no new uses | ## Why labels are promises, not decorations A label only helps if the system **keeps the promise it makes**: - If a stable component breaks without a major release, teams stop trusting the label and start pinning old versions or copying code. - If an experimental component is quietly treated as permanent, the system cannot change it without breaking people who reasonably believed it was stable. - If deprecated components never name a replacement, consumers have nowhere to go and the label is just a warning sign. The label also sets expectations about **support**. A team that reports a layout bug in an experimental component should expect a best-effort response; the same bug in a stable one deserves a prompt fix. The same stages apply on every platform the system ships to, and a component's stage can differ between them: a dial may be stable in the web library and still experimental in the native mobile one. So stage is tracked **per platform**, and the design library asset carries a stage too, so designers do not specify an unfinished component into a production screen without knowing it. ## Deciding whether to use a component at each stage Consider a smart-home control app whose teams are choosing components for a new release: 1. The **device tile** is stable, so the team uses it everywhere, including the critical 'unlock the front door' flow. 2. The **energy-usage chart** is beta. The team uses it on the insights screen, subscribes to the system's release notes and budgets time for one upgrade. 3. The **thermostat dial** is experimental. The team tries it in an internal pilot, sends feedback, and keeps the proven stepper control on the production screen until the dial matures - unless they explicitly accept the risk of rework. 4. The **old scene picker** is deprecated. The team does not add new uses and follows the documented replacement when it next touches that screen. That decision process is only possible because every stage says what it guarantees. ## Where stage and version meet Most systems publish components in versioned packages. A common arrangement is that **only stable (and sometimes beta) components are covered by the package's compatibility promise**, while experimental ones are explicitly excluded and marked so. That keeps the package's version meaningful while still letting new ideas evolve quickly. ## Common mistakes - Treating the label as a quality score rather than a statement about **change and support**. - Assuming beta means 'unusable'; many systems ship beta components in production with a clear upgrade expectation. - Assuming deprecated means 'already broken'; it keeps working until removal, so there is time to migrate. - Building a critical flow on an experimental component without telling the system team, who then cannot warn you before it changes.
- Is it ever reasonable to use an experimental design-system component in production?Yes, if the team accepts the risk knowingly: it is a non-critical screen, the team tells the system team it depends on the component so it can be warned before changes, and it budgets for rework. What is unreasonable is doing it silently in a critical flow and expecting stable-level guarantees.
- What should a stable label promise about visual changes, not just API changes?Consumers build layouts around a component's size, spacing and states, so a stable promise usually covers visual behaviour too: dimension or layout changes that could break a screen are treated as breaking and announced like API changes, while refinements that keep the footprint, such as a colour tuned within its token, can ship in minor releases.
Maturity labels work like a restaurant menu: experimental components are the chef's specials that may be gone next week, stable ones are the permanent menu the kitchen commits to, and a deprecated dish is still served while the menu points you to what replaces it.
saying these in an interview costs you the question
- Beta components are unusable and must never appear in production.
- A stable component can change its API in any release if the change is small.
- Deprecated components stop working as soon as they are marked deprecated.
- Maturity labels are decoration; teams should read the code to judge stability.
- Every design system uses exactly the same four stages with the same rules.