Insights
Central, federated or hybrid design system governance, the decisions every model must assign, and how to tell whether yours works. A design system is governed well when every product team knows who can propose a change, who accepts or rejects it, what evidence it needs, and how an accepted change reaches their product.
Insights · Design systems
A design system is governed well when every product team knows who can propose a change, who accepts or rejects it, what evidence it needs, and how an accepted change reaches their product. There are three common models: central (one system team decides), federated (people from product teams decide together) and hybrid (a core team owns the foundations, and domain patterns are owned closer to the products that use them). Choose the one that matches how many products you run and who has protected time to run the system, then judge it by a single test: is the supported route faster and more predictable for a product team than building its own component?
Governance is the route by which a design system takes in evidence, makes decisions and gets change into products. It should not turn into a committee that guards the library from the teams who need it. For the short definition, see our design system governance entry; this page covers the models, the decisions inside each, and how to choose.
The three models
| Model | Who decides shared changes | Fits when | Strains when |
|---|---|---|---|
| Central | A dedicated system team that builds and supports the system for product teams | A few products, and maintainers with protected time | Requests outnumber what the team can review, so product teams wait or build locally |
| Federated | People from several product teams decide together, with system work as part of their product jobs | Product teams share authority and can give engineering capacity | Nobody's time on the system is protected, and ownership blurs |
| Hybrid | A core team owns foundations; domain teams own the patterns for their area | A product family with shared foundations and distinct domains | The line between core and domain is not written down |
The central and federated team models were set out by Nathan Curtis in 2015 in Team Models for Scaling a Design System, which also describes a solitary model in which one team makes its system available to others while its efforts stay focused on its own product's needs. The survey below uses "hybrid" for the mixed arrangement, and so does this page.
How common each model is, and where each strains, shows in the zeroheight Design Systems Report 2026, a survey of 147 design system practitioners run by a documentation software vendor. Respondents described their structure as centralised (51%), hybrid (31%) or federated (13%). Asked whether they had enough people, 53% of centralised teams, 68% of hybrid teams and 74% of federated teams said they did not. Federated respondents named "no dedicated time/resources" and "unclear ownership/accountability" among their problems; hybrid respondents named unclear ownership and difficulty getting dedicated contributor time. The figures are self-reported and the sample is small, but in our reading they point the same way as the table: the less central the model, the more it depends on agreed capacity and clear ownership.
The seven decisions every model has to assign
A model is only a label until it says who holds each of these decisions. The table below is our judgement, drawn from the public systems in the next section; adapt it rather than adopt it.
| Decision | Central | Federated | Hybrid |
|---|---|---|---|
| Propose a change | Any product team, through one intake | Any participating team, through one shared intake | Any team; the request is routed to the core or domain owner by layer |
| Accept or reject | The system team | The group of product representatives, with one named person to break ties | Core team for foundations; domain owner for domain patterns; core team for anything that changes a foundation |
| Evidence of reuse | Written threshold set by the system team | Written threshold agreed by the group | Core threshold for foundations; domain threshold for domain patterns |
| Accessibility check | The system team, before release | A named reviewer the group agrees, before release | Core team sets the standard; each owner checks their layer against it |
| Release and versioning | The system team | One named release owner | Core releases foundations; domain libraries state which core version they support |
| Deprecation and migration | System team announces; consuming teams migrate on a stated timeline | The group agrees the timeline; a named owner announces it | Each layer's owner, with core changes announced first |
| Exceptions | System team grants and records local variations | The group grants; the requester records | Domain owner grants within the domain; core team for foundation overrides |
In our view, two rows matter most. "Accept or reject" needs a named person, not a forum, because a forum without an owner can leave two disagreeing teams without a decision. "Exceptions" needs a recorded route, because without one a local variation has nowhere to go but a silent fork. Our design systems for SaaS guide covers the first questions a new system should answer about who decides; this table is what those answers grow into once several teams depend on the system.
Write each decision down where the requester can read it. In our design system governance and adoption work, every shared decision gets one record: the product need, the teams affected, the existing pattern, evidence of reuse, the proposal and its accessibility effect, the design and code owners, the decision itself, and the release, migration and adoption evidence that follows. Your organisation keeps the authority to decide and the time to run the model.
What public design systems write down
Some organisations that run their systems in-house publish their governance openly. Each one below makes the decisions explicit in a different way.
Who can propose, and where. The U.S. Web Design System lets anyone suggest a component, starting as a GitHub discussion. If the discussion shows support, the core team turns it into a formal proposal, opens a 45-day comment period, then evaluates it and announces the outcome. Atlassian sets a narrower door: its contribution page says it is, for now, accepting contributions only from internal Atlassians, takes fixes and small enhancements that do not break existing behaviour, and may be unable to take larger contributions such as new components or major enhancements that need system-wide coordination.
Who accepts. IBM Carbon separates the two gates in its product development lifecycle: the community is the first approval gateway, and only the Carbon team can move an asset from discovery to delivery in core Carbon or Carbon for Products. The same page names business impact as the most important factor in prioritising contributions.
Evidence of reuse. The GOV.UK Design System publishes contribution criteria: a proposal must be useful (evidence that it would be useful for many teams or services) and unique (it does not replicate something already in the system). Carbon's discovery criteria ask the same two questions, and once an asset reaches delivery its milestones include identifying 5 to 8 stakeholder teams for early usage and feedback.
The accessibility check. Before publication, GOV.UK requires a component to be usable (tested in user research and shown to work with a representative sample of users, including people with disabilities) and versatile, which includes being tested and shown to work with a range of browsers, assistive technologies and devices. USWDS says it prioritises issues that affect accessibility.
Release and versioning. The Semantic Versioning specification gives the shared vocabulary: a major version for incompatible changes, a minor version for backward-compatible additions, a patch for backward-compatible fixes. Carbon puts breaking changes behind a feature flag while a component is in preview.
Deprecation and migration. Semantic Versioning recommends documenting a deprecation and shipping it in at least one minor release before the feature is removed in a major release, so consumers can move across. GOV.UK states in its component lifecycle that it deprecates components that do not adapt to evolving user needs, research and technology.
Trials. None of these pages sets out an exception route for product teams; the nearest public example is a middle route between "in" and "out" in the same GOV.UK lifecycle: a trial status for components that might not meet all the criteria, which become stable after six months if no negative feedback arrives.
Layers. Carbon describes itself on its about page as a foundation that multiple systems extend: a core, a specialised Carbon for Products layer maintained by a dedicated team, and community-maintained packages for other contexts. In our reading, that is the hybrid model written down.
These are large public systems, and their processes carry weight a ten-person product company does not need. What transfers is the habit of writing each decision down where the requester can read it before asking.
Which model fits your organisation
Pick the model from how your products are split and who has time for the system, not from how big you hope the system will become.
| If your organisation looks like this | Start with | The one thing it must have |
|---|---|---|
| One product, or a few, and someone whose job includes the system | Central | A named owner with protected time and authority to accept or decline |
| Several product teams, each with designers and engineers who can give time, and no separate system team | Federated | Agreed time on the system in each team's plan, and one named release owner |
| A product family with shared foundations and distinct domains (for example, trading and reporting) | Hybrid | A written line between what is core and what each domain owns |
| No one has protected time for the system | None yet | Fix capacity first; no model works on goodwill |
A small team should not inherit enterprise ceremony. A product family should not rely on informal memory. If you are a team of two, the proportionate version is one owner and a short page of rules, as our design systems for SaaS guide sets out in its step on who decides.
Signs that you have outgrown your model: requests wait without a decision, the same component is rebuilt in several products, and decisions are made in chat threads nobody can find a month later. To see where governance sits against your other gaps, the design system maturity model places it alongside adoption, contribution and documentation.
The test: is the supported route faster than a fork?
Put any governance model to one test: if the supported route is slower or less predictable than building a local component, bypassing the system becomes a rational choice. A product team under a deadline may fork, and it would be right to. Governance has to make contribution and exceptions clearer than silent forking.
That means publishing three things a requester can plan around:
- A response time. Not a release date for every request, but when they will hear a decision.
- The full set of outcomes. Reuse what exists, extend it, add something shared, keep it product-specific, reject it with stated reasons, or retire something. "Keep it local" is a legitimate decision when it is recorded with an owner and a reason.
- An exception route. How to ship a variation now, how it is recorded, and when it is reviewed for convergence or retirement.
Research on design system practice, though thin, points to the same tension. In interviews with nine design system project leaders, conducted in 2019 (Lamine and Cheng, accepted in Empirical Software Engineering, 2022), the leaders struggled to keep their systems stable enough to hold lasting design knowledge while flexible enough for different products, and they favoured a bottom-up approach in which components emerge in products and are then elevated into the shared system. A governance model that treats every local component as a violation shuts off that route.
How to tell whether the model works
Component counts do not show whether governance works. They show what was built, not whether teams route their decisions through it. Look at evidence from product delivery instead:
- time from a proposal to a decision, and from a decision to a release;
- the share of requests with a recorded outcome, including "keep it local" and "reject";
- local forks of shared components, and the reason each exists;
- which version of the system each product runs, and how far migrations have got;
- accessibility defects that recur in shared components;
- whether people in product teams can name who decides a shared change.
Open contribution is not the same as a working route. In the same zeroheight survey, 65% of respondents said anyone on the product team can contribute to their system, while 36% were satisfied with their contribution process and 29% were dissatisfied. The two figures come from separate questions and do not show cause, but they are a useful reminder that a contribution page is not a contribution path. Release notes were the most common governance ritual or artefact (56%), ahead of a roadmap (48%) and office hours (33%).
For the difference between a system being available and teams using it repeatedly in real product work, see our design system adoption entry.
