skip to content

In a design system, what evidence should a component show before it is promoted from beta to stable, and who should decide?

level: middleimportance: should knowfreq 34%

answer

  1. evidence, not elapsed time
  2. used by more than one product
  3. the interface has stopped moving
  4. release bar cleared, no serious issues open
  5. a named group, public criteria

basics

~20 s

Evidence of real use and a settled interface: it clears the release bar, runs in production in more than one product, has gone a while without breaking, and has no serious issue open. The system team decides, with design and engineering signing.

solid answer

~40 s

Promotion to stable is a **commitment**: from then on, breaking changes cost a major release and a migration for every consumer. So I would ask for evidence that the component will not need to break soon. It has **cleared the full release-readiness bar**; it is **used in production by more than one product**, so it is not shaped around one team's screen; its **interface has been unchanged for several releases**; **feedback from those consumers is resolved** and no serious defect is open; and the docs are complete. The decision belongs to the **system team**, with a designer and an engineer both signing, against **criteria published in advance** so contributors know the target. Consumers' input is evidence, not a vote. Time in beta matters only as a proxy for that evidence, never on its own.

go deeper

for a junior

Recall that stable is a stronger promise than beta, so promotion needs evidence such as real usage and an interface that has stopped changing.

for a middle

Explain each criterion and why it predicts stability, and why elapsed time on its own is a poor proxy for readiness.

for a senior

Show how you would run promotion reviews across many contributors: published criteria, design and engineering sign-off, and handling components stuck in beta or stable only in practice.

for a principal

Weigh strict criteria that protect consumers against slower promotion that leaves teams on beta longer, and decide how much evidence the organisation can afford to demand.

## Why promotion is a commitment In a design system with **maturity stages**, promoting a component from **beta** to **stable** changes what the system promises. A beta component may still break, with notice. A stable one may break only in a major release, with migration guidance for every consuming team. Once many teams build on a stable component, changing it becomes expensive. So the promotion question is really: **is this component unlikely to need a breaking change soon?** ## The evidence to ask for | Criterion | Why it matters | Typical evidence | |---|---|---| | Release bar cleared | stable implies full accessibility, theming, localisation, docs and tests | the completed readiness checklist | | Used by more than one product | proves the design is general, not one team's screen | production usage in two or more products | | Interface settled | stable means no breaks soon | several releases with no breaking change to props, variants or behaviour | | Feedback resolved | consumers found the rough edges during beta | closed feedback items, no serious open defects | | Docs complete | stable components are self-serve | usage guidance, examples, accessibility notes | | An owner | stable implies ongoing support | a named maintainer or team | The number of consuming products and the length of the settling period are **conventions** each system chooses; two independent products and a few release cycles are common choices, with the reason being that one consumer cannot distinguish a general design from a local one. ## Evidence, not the calendar A frequent failure is **time-based promotion**: 'it has been in beta for three months, so it is stable'. Time alone proves nothing if nobody used the component in that period. Time matters only because it gives real use a chance to surface problems. A component that sat unused in beta for a year is no more ready than on its first day. The reverse also happens: a component used heavily in production by many teams, but never formally promoted, has become **stable in practice**. The system is already paying stable-level costs for every change, so it should either promote it and make the promise explicit, or fix whatever is blocking promotion. ## Who decides 1. **The system team owns the decision**, because it will carry the support and compatibility cost. 2. **Design and engineering both sign**, since each sees different risks: a designer spots a pattern that does not fit the rest of the language; an engineer spots an API that will not survive new requirements. 3. **Criteria are published in advance**, so contributors from product teams know what 'ready for stable' means and do not experience promotion as arbitrary. 4. **Consumers provide evidence**, not votes: their production use and feedback are inputs. Record each promotion with the evidence behind it, so a later reader can see why the system committed. Where a component ships to both web and native mobile, each platform's implementation is usually promoted on its own evidence, because an interface that has settled on one platform may still be moving on the other. ## Earlier stages have criteria too Promotion from **experimental to beta** usually asks for less: a real problem the component solves, a spec, at least one committed consuming team, and a design and API the team believes in. The goal of experimental is learning, so the bar to enter it is low and the bar to leave it is evidence that the idea works. ## A worked example In a smart-home control app, a **scene scheduler** component has been in beta for two releases. It is used by the app's automation screen and by the installer's configuration tool. Its interface changed once, one release ago, to support sunrise-relative times; the change came from the second consumer. The system team decides to wait one more release: the recent break shows the interface was still moving, and promoting now would risk a major release soon after. When the next release passes with no interface change and both teams report no open issues, it is promoted. ## Common mistakes - Promoting because a deadline or a roadmap says so. - Promoting a component used by only its original requester. - Letting one enthusiastic contributor promote their own component. - Leaving heavily used components in beta indefinitely, so the label stops meaning anything.

  • Can a stable design-system component be moved back to beta if its design turns out to be wrong?
    Rarely, because demotion withdraws a promise consumers relied on. The usual path is to keep the stable component supported, introduce the new design as a separate experimental or beta component, and once it is stable, deprecate the old one. Demotion is reserved for serious cases and is announced like a breaking change.
  • What do you do with a beta component that never gains a second consuming product?
    Treat it as evidence that it may be product-specific rather than a system component. Options are to keep it in beta with a review date, generalise it with a second team's needs in mind, or hand it back to the requesting product to own locally. Promoting it to stable on one consumer's use would lock in that team's assumptions.
  • Why should promotion criteria be published before a component enters beta?
    Contributors can then build toward a known target, gather the right evidence during beta, and avoid feeling that promotion depends on who they know. Published criteria also make the decision reviewable later: anyone can check why a component was promoted.

saying these in an interview costs you the question

  • A component becomes stable once it has spent a fixed time in beta, whatever its usage.
  • One product using a component in production proves it is general enough for stable.
  • The contributor who built a component should decide when it is stable.
  • Promotion is a formality, since stable and beta make the same promises.
  • Heavily used components can stay in beta indefinitely without any cost.