Governing a design system at scale

Governance answers three questions: who runs the system, how it changes, and how you know people are using it well. Without answers, a system either freezes, because nobody may touch it, or splinters, because everyone does.

Governance sounds like bureaucracy, but done well it is mostly a few clear habits. This part covers the ones most teams end up needing.

Team models

Nathan Curtis of EightShapes described the common ways a design system team is organised. They remain a useful map:

A contribution process

People will ask for new components and changes. A visible process turns those requests into improvements instead of side forks:

1. 01Request. An issue or form: what problem it solves and where it is needed.
2. 02Triage. Does something similar already exist? Is this for one product or for many?
3. 03Design and proposal. Use cases, variants and accessibility, written up as an RFC that others can comment on.
4. 04Review by the system team, an engineer and someone focused on accessibility.
5. 05Build in Figma and in code.
6. 06Document and release: version, changelog and an announcement.
7. 07Follow up on adoption. Check that the teams who asked for it actually use it.

System component or local snowflake?

Not every request belongs in the system. A common rule of thumb: when a pattern is needed in about three places or more, bring it into the system. If only one screen needs it, let it live in that product as a local component. It can be promoted later if others start to need it.

Versioning and releases

Most systems use Semantic Versioning: MAJOR.MINOR.PATCH. The number tells consumers how careful they need to be when they update.

• Changelog. Group every release under Added, Changed, Deprecated, Removed and Fixed, the categories from Keep a Changelog.
• Deprecation, not deletion. Mark the old part deprecated, publish a migration guide, and remove it a release or two later.
• A predictable cadence. Small, regular minor releases with major releases spaced further apart, so teams can plan upgrades.

## 2.0.0
### Changed
- Button: prop `type` renamed to `variant`
### Removed
- LegacyTag (deprecated in 1.8.0, use Badge)

## 1.9.0
### Added
- Button: `loading` state
### Deprecated
- Token color.brand-blue, use color.bg.brand

Measuring adoption and health

A system nobody uses has failed, however polished it is. These signals show how it is doing:

When a team keeps detaching components

A product team detaching components is a signal, not a crime. Treat it as research:

1. 01Find out why, through a short conversation or the usage data.
2. 02Look for the gap. The component may be too rigid, or there may be a use case it never covered.
3. 03Close it by bringing the case in through the contribution process, or by documenting the right alternative.
4. 04Keep tracking the detach rate to see whether the change worked.

Habits that help at scale

• Linting. A Figma plugin flags colours and spacing that don’t come from tokens; in code, Stylelint rules do the same.
• Office hours. A regular slot where anyone can bring questions about the system.
• Design critique with a system review before large features ship.
• A single source of truth. Token JSON in Git, with Figma and code both built from it.
• Theming through semantic tokens and modes, for several brands or products from one system.
• A documentation site, built with a tool such as Zeroheight or Supernova, or your own, for example Storybook with MDX.

Next in the series

Governance keeps a system healthy, but the system exists to serve users. Part 6 turns to UX principles, starting with Nielsen’s usability heuristics, which give you reasons for a design decision rather than taste.