skip to content

In a design system, how do the contribution tiers of fix, enhancement and new component differ in the path each follows?

level: middleimportance: should knowfreq 34%

answer

  1. same stages, different weight
  2. what changes for consumers
  3. matching the spec vs changing the API
  4. enhancements risk option sprawl
  5. new components need proven shared need

basics

~20 s

A fix makes a component match its existing spec and needs light review; an enhancement extends an existing component's API and needs design and API review; a new component needs a proposal proving shared need before anything is built.

solid answer

~40 s

All three move through the same stages (proposal, review, build, release), but the tier decides how heavy each stage is. A **fix** makes a component match its own spec, such as a misapplied token or broken truncation; it needs a short report and code review and can ship in the next release. An **enhancement** adds a variant, option or state to an existing component, so it changes the public API and the design library together; it needs design and API review against the whole system, because every consumer inherits it. A **new component** needs the heaviest front end: a proposal showing the need recurs across teams and nothing existing covers it, reviewed before any build starts. Tiering keeps small fixes fast and puts scrutiny where the long-term ownership cost is.

go deeper

for a junior

Recall the three tiers with one example each, and that all of them pass through proposal, review, build and release.

for a middle

Explain that the tier is set by what changes for consumers, and why enhancements risk option sprawl while new components carry long-term ownership cost.

for a senior

Show how you classify requests at intake, catch misfiled contributions, and put an early proposal review in front of new components so nobody builds work that will be rejected.

for a principal

Discuss how tier definitions and their review depth trade contributor speed against system coherence, and how you would retune them as the number of contributing teams grows.

## Why a design system tiers contributions A **contribution** is any change to a design system proposed or built by someone outside the core system team, usually a product team that needs something the system does not yet provide. Contributions differ enormously in risk. Correcting a misapplied color token affects little beyond the bug; adding a new component creates something the system must document, test, support and keep compatible for years. If every contribution goes through the same heavy process, small fixes wait weeks and contributors give up. If every contribution goes through a light process, the system accumulates half-considered components. **Tiers** solve this by matching the depth of each stage to the size of the change. ## The three tiers at a glance | Tier | What it changes | Example on an online learning platform | Up-front proposal | Review depth | |---|---|---|---|---| | **Fix** | Makes a component match its existing spec | The course card clips long course titles instead of wrapping as documented | A short report of the defect | Code review and a check against the spec | | **Enhancement** | Extends an existing component's public API or design | Adding a 'certificate awarded' status to the course card's status area | A proposal with use cases and the proposed option | Design and API review across all consumers | | **New component** | Adds something the system did not have | A transcript panel that follows the lesson video | A proposal proving recurring, shared need | Full design, API, accessibility and documentation review | The tier is decided by **what changes for consumers**, not by how many lines of code are touched. A one-line change that alters the default spacing of every card is not a fix if the spec never promised that spacing. ## The shared lifecycle Every tier moves through the same four stages; only their weight differs. 1. **Proposal** - the contributor describes the need, the context and the intended change. For a fix this is a bug report; for a new component it is a written case. 2. **Review** - the system team, with design and accessibility reviewers where relevant, decides whether the change belongs in the system and whether its shape is right. 3. **Build** - design assets and code are produced, with documentation and tests, until the change meets the system's release-readiness bar. 4. **Release** - the change ships in a system release with a note telling consumers what changed. ## How the tier changes each stage - **Fix.** The proposal can be a sentence and a screenshot. Review asks one main question: does the component now match its spec? The build is usually small, and the change can ship in the next release without a design discussion. - **Enhancement.** The key risk is **option sprawl**: every new option multiplies the combinations a component must support, document and test. Review therefore asks whether the need is shared, whether an existing option or a composition already covers it, and whether the name and behaviour fit the rest of the system. The design library and the code change together so they stay in parity. - **New component.** The key risk is **ownership cost**. Review happens twice: once at the proposal, before anyone builds, to decide whether the system should own this at all, and again when the build is ready. Skipping the first review is the classic cause of contributions rejected after weeks of work. ## Misclassified contributions Many problems come from contributions filed under the wrong tier: - An enhancement disguised as a fix ('the card should also show a certificate status') skips API review and lands an option nobody designed for the whole system. - A new component disguised as an enhancement ('add a transcript mode to the video player') bloats an existing component with a second job. - A fix treated as an enhancement stalls a genuine defect behind a design discussion it does not need. The remedy is to **classify at intake**: whoever triages a request assigns the tier first, and moves it between tiers as understanding improves. ## Writing the tiers into contribution guidelines **Contribution guidelines** are the system's published description of how to contribute. For tiers to work, the guidelines should say, for each tier, what to submit, which reviews apply, what the build must include and roughly how long each step takes. Templates for a fix report and for a new-component proposal remove guesswork on both sides. The same structure applies whether the contribution targets web components, native mobile components or the design library: the tier describes the change to the system's contract, and that contract spans every platform the system serves.

  • Why should a proposed new component be reviewed before any build starts?
    Because the most expensive question, whether the system should own this at all, has nothing to do with build quality. Answering it after weeks of work either wastes that work or pressures the team into accepting something it does not want to maintain. An early review costs a short conversation and can redirect the contributor to an existing component, a local build or a shared plan.
  • Who should decide a contribution's tier, the contributor or the system team?
    The contributor proposes a tier, but whoever triages intake for the system confirms it, because contributors tend to underestimate how far their change reaches. The tier can move as review uncovers more: a reported fix that turns out to need a new option moves into the enhancement path, with the reviews that path requires.

saying these in an interview costs you the question

  • Every contribution should go through the same full review, however small.
  • The tier is decided by how many lines of code the change touches.
  • Building a new component fully before proposing it saves the system team time.
  • Adding a new option to an existing component is just a fix.
  • An enhancement only needs code review because the component already exists.