Design system governance that doesn't slow teams down
Pick a team model on purpose, sort every change into the right lane, write decisions down, and version the system like the library it is.
In zeroheight's Design Systems Report 2026, which surveyed 147 people, 3 in 5 design system teams said they didn't have enough people to meet their goals. Route every change through that team's approval and you get a queue staffed by people who are already behind.
Design system governance is the set of rules for who can change the system, how a change is proposed and reviewed, and how the people using it find out. Good governance makes the common path fast (fix a bug, extend a component) and keeps the rare path deliberate (add a component, remove one, rename a token).
Key takeaways
- Nathan Curtis's three team models, solitary, centralized, and federated, still describe the real choice: who decides, and how close they sit to product work.
- Sort contribution requests by size, because a bug fix and a new component deserve different reviewers and turnaround times.
- One-page decision records with context, status, and consequences stop the same debate from recurring.
- Semantic versioning gives consumers a contract: deprecate in a minor release, remove only in a major one.
- Measure governance by flow and adoption, such as contribution lead time and detach rates, not by components shipped.
Which team model fits your organization?
In 2015 Nathan Curtis described three ways to staff a design system. The models still hold.
| Model | Who decides | Works when | Watch for |
|---|---|---|---|
| Solitary | One product team builds for itself and shares the result | One product dominates | Other teams' requests feel like a distraction |
| Centralized | A dedicated team that doesn't design products | Many products need consistency | Distance from product context |
| Federated | Designers from several product teams, together | Product teams have designers with time to commit | Divided loyalties and scattered decisions |
Curtis is blunt about the first model: "Overlords don't scale." He describes the centralized team's position as tenuous, and warns that the federated model means lots of cooks and still needs dedicated staff to document the system.
Many mature teams combine a small central core that owns quality and releases with federated contributors who bring product context. Whatever you choose, write it down.
A contribution workflow that keeps moving
The bottleneck in most systems is that every request, from a typo to a new data table, enters the same queue. The five-lane contribution workflow gives each size of change its own lane:
| Lane | Example | Who approves | Target turnaround | Version bump |
|---|---|---|---|---|
| Fix | Missing focus ring on a menu item | Any maintainer | Days | Patch |
| Extend | A new xs size on Button | One system designer and one engineer | One to two weeks | Minor |
| Propose | A pattern for bulk actions | System team, with product evidence | Decision in two weeks | None yet |
| Add | Build and publish the bulk actions bar | System team, in Figma and code | One to two sprints | Minor |
| Remove | Retire a component for a replacement | System team and affected product leads | One deprecation cycle | Major |
The Propose lane is where most fights happen, so give it entry criteria. The GOV.UK Design System's criteria are a good model. At the proposal stage, a new component must be useful (evidence that many teams need it) and unique (it doesn't duplicate anything). Before publishing, it must be usable (tested with real users, including disabled people), consistent (built from existing styles and components), and versatile (works across services, browsers, and assistive technologies).
Publish the queue, and answer every proposal within the target time, even when the answer is "not yet", because silence pushes teams to build their own.
A contribution workflow should make the right answer obvious before anyone asks for a meeting.
Why should a design system keep decision records?
Every system eventually re-argues the same questions: why Button has no tertiary variant, why tooltips never contain links. Decision records end the loop.
The format comes from software architecture. Michael Nygard's 2011 post proposed five parts: Title, Context, Decision, Status, and Consequences. Status says whether a decision is proposed, accepted, deprecated, or superseded, and a reversed decision keeps its record with a pointer to its replacement.
Keep each record to one page and link it from the component page it affects. When someone asks for the tertiary button again, you send a link instead of reopening the debate.
How should you version and deprecate components?
Treat the system as a library with an API. Semantic Versioning 2.0.0 sets the rules: a major version for incompatible API changes, a minor version for backward compatible additions, and a patch for backward compatible fixes.
Under the spec, marking public functionality as deprecated calls for a minor release, and at least one minor release should contain the deprecation before a major release removes it. A practical cycle:
- Write a decision record naming the replacement and the reason.
- Ship a minor release that marks the component deprecated in code, with a development warning and a
@deprecatednote in its types. - Mark it deprecated in Figma, in the component's name and description, so designers stop placing new instances.
- Publish a migration guide with a before and after example.
- Track remaining usage, then remove the component in the next major release.
Version tokens the same way. Renaming a token breaks every consumer that references it, even when the value never changes.
Which governance metrics matter?
Count flow and adoption, not output:
- Contribution lead time per lane, from request to release.
- Proposal response rate within the target time.
- Adoption across products, in code imports and design file usage.
- Detach rate per component. Figma's library analytics reports insertions, detaches, and usage by team and file on Organization, Enterprise, Government, and Education (K-12) plans.
- Deprecated usage remaining before each major release.
These numbers also make the case upward. The same zeroheight report found only 32% of respondents satisfied with how their organization secures buy-in, down from 42% the year before. A chart of lead time falling while adoption rises is harder to ignore than a roadmap.
Where Pegasus fits
Pegasus ships a Figma library of 1,540 components plus matching React code, with the same component names, variant structure, and tokens on both surfaces. Your governance effort goes into your tokens, your product-specific additions, and your usage rules rather than into building foundations.
One token source themes both the Figma variables and the code's theme object, so a brand decision is one token change rather than a component-by-component review. Matching names mean a decision record or a deprecation notice can cite one name that designers and engineers both recognize.
Storybook ships with stories and tests for the components, which gives reviewers in the Fix and Extend lanes a place to check behavior before approving. Updates are free under a perpetual license, so adopting a new Pegasus release is a versioning decision for your team, not a purchasing one.
FAQ
What is design system governance?
Design system governance is the set of rules for who can change a design system, how changes are proposed, reviewed, and released, and how consumers are told. It covers the team model, the contribution process, decision records, versioning, deprecation, and the metrics that show whether the system is working. Good governance keeps small changes fast and big changes deliberate.
What is the best team model for a design system?
No single model wins. Nathan Curtis's solitary model suits one dominant product, the centralized model suits organizations that need consistency across many products, and the federated model suits teams with product designers who can share decisions. Many mature organizations combine a small central team with federated contributors who bring product context.
How do you handle contributions to a design system?
Sort contributions by size into fixes, extensions, proposals, additions, and removals, and give each lane its own approver, turnaround target, and version bump. Set clear criteria for new components, such as the GOV.UK Design System's useful, unique, usable, consistent, and versatile tests. Publish the queue and answer every proposal within a set time.
How do you deprecate a component in a design system?
Write a decision record that names the replacement, then mark the component deprecated in a minor release, with a code warning and a note in Figma. Publish a migration guide, track remaining usage, and remove the component only in the next major release. Semantic Versioning recommends at least one minor release containing the deprecation before removal.
Sources
- Team Models for Scaling a Design System, Nathan Curtis, Center Centre (2015)
- Design Systems Report survey and 2026 findings, zeroheight (2026)
- Contribution criteria, GOV.UK Design System (2026)
- Documenting Architecture Decisions, Michael Nygard, Cognitect (2011)
- Semantic Versioning 2.0.0, semver.org
- View and explore library analytics, Figma Help Center (2026)
One system. In Figma and in code.
Pegasus ships 1,540 components, 470 tokens, matching React code, Storybook, and a local MCP server. $149, one-time.
Get the full system