Skip to content
UX Atlas
Plate SYS·004 · Design systemGrid D4 · Rev. 2026-09-14

Design System Governance

Who decides what goes in, how changes are proposed, and how the system stays coherent as more people touch it.

Design systemCraft conventionAdvanced

Definition

Governance covers ownership, contribution, review and decision-making for a design system. It is what prevents a system from either ossifying or fragmenting as an organisation grows.

Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.

On this plate
  1. 1Definition
  2. 2Governance models
  3. 3What has to be written down
  4. 4Who decides what
  5. 5Process that survives growth
  6. 6Commonly confused with
  7. 7Local chart
  8. 8Continue from here

Reach for this when

  • A system is used by more than a handful of teams.
  • Contribution has stalled or forking is increasing.
  • Defining ownership for a new system.

Common mistakes

  • No documented contribution path.
  • Review that takes so long teams route around it.
  • Abstraction before the need is proven.
  • Exceptions granted verbally.

Governance models

ModelHow it worksFails when
CentralisedA dedicated team owns everythingThe team becomes a bottleneck and loses touch with product needs.
FederatedRepresentatives from product teams share ownershipNobody has time, and decisions stall.
HybridA core team owns foundations, product teams contribute componentsThe contribution path is undefined, so nobody uses it.
Open contributionAnyone can propose, a small group reviewsReview capacity is exceeded and quality drifts.

What has to be written down

  • How to propose a new component, and what evidence is required.
  • The criteria for promoting something from one team's code into the shared system, usually a threshold of independent need.
  • Who reviews, and what the service level for review actually is.
  • The deprecation process, including notice periods and migration support.
  • How exceptions are granted and recorded, since undocumented exceptions become precedents.

Who decides what

Governance is mostly one question asked repeatedly: who can say yes to this, and who has to be asked first.

DecisionDecided byConsulted
Changing a primitive or the scale behind itCore teamBrand and accessibility, before the change rather than after.
Adding a semantic tokenCore teamThe teams that asked for it.
Adding a variant to an existing componentCore team, on evidence of three independent usesThe contributing teams.
Promoting a local component into the systemCore team with the contributing teamsAccessibility, and the engineers who will maintain it.
Granting an exceptionCore team, recorded with an expiry dateThe requesting team.
Deprecating anythingCore teamEvery consuming team, before the announcement rather than in it.

Process that survives growth

Do

  • Publish the review turnaround you will actually meet, then meet it.
  • Record every exception with a reason and an expiry, and review the list on a schedule.
  • Give each decision a designer and an engineer together. Split ownership produces two systems that share a name.
  • Make the escape hatch visible and logged, so routing around the system becomes data rather than a secret.

Do not

  • Do not convene a meeting where a written proposal and a named approver would do.
  • Do not grow governance faster than the system. A five-person product needs a rule of thumb, not a board.
  • Do not treat a fork as disloyalty. It is a defect report about the API, filed in code.
  • Do not change foundations without naming the migration owner in the same decision.

Commonly confused with

Close neighbours that get substituted for each other. The difference is stated first, then the condition that picks one over the other.

vs.

Contribution Models

Design system

The defined path by which a team proposes, builds and lands a change.

Key difference

Governance is who decides and how coherence is kept. A contribution model is the route a product team takes to get work into the system. Governance without a contribution route produces a queue; contribution without governance produces a pile.

Use Design System Governance when

  • Nobody can say who owns a decision, or everything needs one person.
  • The system is fragmenting, or ossifying because nothing gets approved.
  • The question is authority and standards.

Use Contribution Models when

  • Teams are forking because waiting costs more than duplicating.
  • Someone has built something worth promoting into the system.
  • The question is process, entry criteria and who does the work.

Learn about Contribution Models

Local chart

SYS·004 · Region VI · Grid D4

This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.

Consistency and StandardsHEUR·004 · PRINCIPLES BEHIND THISContribution ModelsSYS·007 · COMMONLY CONFUSED WITHMigrating Product Teams onto a Design SystemCASE·003 · PRACTICAL EXAMPLEDeprecationTERM·089 · SHORT DEFINITIONDesign SystemTERM·084 · SHORT DEFINITIONComponent API DesignSYS·002 · RELATED CONCEPTDesign System AdoptionSYS·005 · RELATED CONCEPTDesign System AuditsSYS·011 · RELATED CONCEPTDesign System DocumentationSYS·003 · RELATED CONCEPTDesign TokensSYS·001 · RELATED CONCEPTVersioning and DeprecationSYS·006 · RELATED CONCEPTColor SystemsFND·026 · RELATED CONCEPT

Continue from here

Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.

Principles behind this

The reasoning this solution is an application of.

Practical example

A worked decision where this was the deciding factor.

Short definition

The one-paragraph version, for when that is all you need.

Related concept

Connected closely enough to change how you apply this.