Design System Governance: Who Decides What Changes and How
Design system governance defines who owns the system, who can contribute, and how changes are approved, versioned, and deprecated. A starter guide for teams.
What problem does governance solve?
A design system rarely fails because it lacks components. It fails because every team builds its own button, its own modal, and its own version of the error color. According to NN/g, governance is one of six dimensions that determine how mature a system is, alongside organizational alignment, team effectiveness, infrastructure, support, and adoption (NN/g: Design-System Maturity).
For NN/g, governance is the operating model for making decisions, accepting contributions and keeping the system coherent while it and the organization change. It covers five topics: contribution models, how deviations are handled, the balance between product expression and brand consistency, versioning and release strategy, and prioritization.
Governance is not bureaucracy. It answers concrete questions that someone will have to answer sooner or later:
- Who decides whether a new component gets added?
- Who reviews a breaking change before it ships?
- What happens when two teams need conflicting variants?
Which ownership models exist?
Figma’s guidance describes three main models (Figma: Design System Governance):
| Model | Who owns it | Advantage | Risk |
|---|---|---|---|
| Centralized | A dedicated team approves every change | High consistency | Bottleneck |
| Federated | Designers across several teams share ownership | Speed and a sense of belonging | Drift: everyone does their own thing |
| Hybrid | The core team owns the foundations; product teams own their patterns | Balance | Gets confusing if the rules are not explicit |
Figma notes that most teams start centralized and move toward a hybrid model as the system scales. For a junior designer, the useful takeaway is that there is no single correct model. The right one matches the size of the team.
How are decisions split?
A practical way to divide decision rights is by reach. Figma suggests that brand-level decisions stay with the team that owns the foundations, because they affect every product that uses the library (for example, a base color token or renaming a shared component). Everything else is a team-level decision and moves faster, such as a new card variant for one team’s workflow.
The GOV.UK Design System also shows a useful pattern. Instead of a single process, it defines stages, from deciding what to work on through to publishing, and assigns a role that drives each stage and a role that supports it. There are nine stages in total. Its contribution model page says there is no one-size-fits-all process (GOV.UK Design System: Contribution model). That page is past its review date (June 2024), so read it as a reference for structure, not as a standard. For the detail of how a proposal flows, see contributing to a design system.
How do you version and deprecate?
Figma recommends short release notes that say what changed and what someone needs to do, posted in the library description or a dedicated channel. For deprecations, it advises giving more lead time, naming the replacement and giving teams a window to migrate before their files break. It does not say how long that window should be, so set yours based on how many teams depend on the component.
A common practice, and not a Figma rule, is semantic versioning:
- Major: changes that break compatibility.
- Minor: new components or variants that remain backward compatible.
- Patch: fixes with no visible change to the API.
A reasonable starting rule: announce a deprecation in the same release that introduces the replacement, and keep the old component working for at least one minor version before you remove it.
When is heavy governance the wrong choice?
If one team of eight people uses the system, a weekly approval committee is a waste of time. NN/g proposes assessing the system’s maturity as a team and repeating the assessment, typically every quarter or after major organizational shifts; the result is a snapshot, not a permanent diagnosis. Use it to decide how much structure is needed instead of imposing the maximum on day one. Start with the lightest process that prevents drift, and add rules when a real problem shows up.
Governance without an owner is not a good idea either. A federated model with no one holding the final say on standards ends up with four versions of the same button.
Illustrative example
Illustrative example: a product team needs a filter chip that the system does not have. Instead of building it inside their own project, they open a request in the system’s channel with a use case and a mockup. The core team checks whether something similar already exists, decides in a short meeting, and if the chip is accepted, it ships in a minor version with release notes. The product team does not wait weeks for a decision that could have been made in ten minutes, because the rules were written down.
To see how this connects to tokens, read Tokens Studio: design tokens from Figma and the article on token architecture. For the visual side of the system, see design system and token parity.
Common mistakes
- Writing a governance model before there is a system to use.
- Having a contribution process without deciding who approves.
- Changing components without release notes, so each team discovers the change when their screen breaks.
- Confusing “more rules” with “more quality”: rules nobody follows protect nothing.
- Leaving deprecation for the end, when twenty files already depend on the old component.
What you can do tomorrow
- Write a one-page document that names the owner of tokens, components, and documentation.
- Define a single channel for change requests and a template with a use case and a mockup.
- Agree on how versions are numbered and where release notes are published.