skip to content

In design-system governance, why should approving a breaking change require different decision rights than approving a new component?

level: middleimportance: should knowfreq 34%

answer

  1. approval weight follows who pays
  2. reversible versus irreversible
  3. additive changes spare consumers
  4. breaking changes cost every consumer
  5. a published decision-rights matrix

basics

~20 s

Approval should scale with who bears the cost and how reversible the change is. A new component is additive and mainly commits its maintainers; a breaking change forces work on every consuming team, so their representatives must help decide.

solid answer

~50 s

**Decision rights** say who proposes, who approves and who must be consulted for each kind of change, and their weight should follow **who pays and how reversible** the change is. A **bug fix** restoring documented behaviour costs consumers nothing, so a component maintainer can approve it. A **new component** is additive — nobody has to change — but it commits the system to maintaining it, and removing it later would itself be breaking; so the core team or council approves it against published criteria of fit and ownership. A **breaking change** makes every consuming team do migration work, so the people bearing that cost, or their representatives, must be consulted and the migration cost weighed before approval. Publishing this as a **decision-rights matrix** stops every change from being argued from scratch and stops the loudest team from deciding by default.

go deeper

for a junior

Recall that different kinds of change — a fix, a new component, a breaking change — have different approvers, and that consumers are consulted before breaking changes.

for a middle

Explain the two questions that set approval weight — who bears the cost and how reversible the change is — and why a new component is additive yet not free.

for a senior

Show how you would draft and publish a decision-rights matrix, timebox each route and keep breaking-change consultation from turning into an indefinite veto.

for a principal

Weigh speed of evolution against consumer trust, and decide how much authority the core team keeps versus delegates as the organisation and the system grow.

## What decision rights are In a **design system** — shared tokens, components, patterns and guidance used by many product teams — **decision rights** define, for each kind of change, who may **propose** it, who **approves** it and who must be **consulted** before it happens. Without them, every change is negotiated from scratch and decisions go to whoever is loudest or most senior in the room. ## Weight follows cost and reversibility Two questions set how heavy an approval should be: 1. **Who bears the cost?** If only the system's maintainers do work, they can decide. If every consuming team must do work, those teams need a voice. 2. **How reversible is it?** A change that can be undone cheaply can be approved quickly. A change that is expensive to undo deserves more scrutiny before it happens. A **breaking change** — one that makes existing uses stop working or change behaviour, such as renaming a property or removing a variant — scores badly on both: every consumer pays for the migration, and once shipped it cannot be taken back without a second breaking change. A **new component** is additive: nobody has to change anything, so it is mostly reversible for consumers — but not free for the system, because once teams adopt it, removing it becomes a breaking change of its own. ## A decision-rights matrix | Change | Example on a benefits service | Proposes | Approves | Consulted | |---|---|---|---|---| | Bug fix restoring documented behaviour | The date input rejects a valid date | Anyone | Component maintainer | — | | Additive property or variant | A compact option for the case-status tracker | Contributor | Component owner and design lead | Documentation owner | | New shared component | A document-upload component | Product team or core team | Core team or council, against published criteria | Accessibility specialist, likely consumers | | Breaking change to a component | Restructuring the error-summary component | Core team | Core lead, with consumer representatives' sign-off | Every consuming team, with a migration estimate | | Foundation change | Changing the base text size for all services | Core team | Core lead and design leadership | All teams | The exact roles vary by governance model — in a federated model the council fills the 'core team' column — but the gradient holds: the more consumers pay and the less reversible the change, the more voices approval needs. ## Why a new component still needs approval It is tempting to say 'additive means harmless, so approve everything'. The costs are real, only deferred: - Every component must be maintained, documented, tested for accessibility and kept in step across design and code. - A component that duplicates an existing one splits usage and creates a future removal. - A component that fits only one team belongs in that team's product, not in the shared system. So approval of a new component asks **fit and ownership** questions — is the need shared, does it overlap anything, who will maintain it — rather than asking consumers to consent. ## Why a breaking change needs consumers in the room For a breaking change the question is different: **is the benefit worth the total migration cost**, and when should it land? Only the consuming teams can say what the change costs them, whether a policy deadline makes this quarter impossible, or whether an automated migration would make it cheap. Approving it without them turns the system team's convenience into everyone else's unplanned work, which erodes trust faster than almost anything else. Consultation is not a veto. The approver collects each team's cost and timing by a deadline, weighs them against the benefit, and decides; evidence such as a count of where the component is used, or an automated migration that makes the change cheap, often settles the question faster than debate. Batching several breaking changes into one planned major release also means teams pay the migration overhead once rather than repeatedly. ## Making it work - **Publish the matrix** where proposers will see it, so the route of each change is predictable. - **Timebox decisions**, so a heavy approval path does not become an indefinite queue. - **Record decisions and reasons** in a log, so later arguments can cite precedent. - **Define an appeal route** for teams that disagree with a decision.

  • How do you stop a heavy approval path for breaking changes from freezing the system?
    Timebox each stage, batch breaking changes into planned major releases rather than trickling them out, and make the cost cheap to assess with a usage count and, where possible, an automated migration. Consultation means collecting cost and timing input by a deadline, not waiting for unanimous agreement; the approver still decides.
  • Who should approve a change to a shared foundation such as the base text size?
    The heaviest route in the matrix: the core team proposes, and core leadership approves together with design leadership, after consulting every consuming team. A foundation change touches every component and every product at once and is costly to reverse, so it warrants more scrutiny than any single component change.

saying these in an interview costs you the question

  • Every change should go through the same approval process for fairness.
  • Additive changes are free, so any new component should be accepted.
  • The system team can approve breaking changes alone; consumers just upgrade.
  • Decision rights are unnecessary if the system team is senior enough.
  • Consulting consumers means a breaking change needs their unanimous consent.