Most design systems do not fail because their buttons are badly designed. They fail in the space between the library and the teams expected to use it.

A product team needs a new interaction. The system team is busy. Someone duplicates a component, changes a few properties and ships. Another team solves a similar problem differently. Six months later, the library is still polished, but the product is full of exceptions. The design system technically exists; its authority does not.

This is a governance problem, although “governance” can sound like a committee designed to slow everyone down. Done well, it is almost the opposite. Good governance makes the correct decision easier, faster and more predictable than inventing a local workaround.

The 2026 Design Systems Report, based on responses from 147 practitioners, is a useful reality check. Only 7% described their systems as fully adopted across all teams; another 31% reported wide adoption. The survey is a snapshot of its respondents, not a census of the industry, but its central tension is familiar: components may be available while consistent usage remains difficult.

My argument is simple: a mature design system needs an operating model, not just a component library. That model should explain who decides, how contributions enter, what happens after release, and how the team knows whether the system is making product delivery better.

Governance needs explicit rules and decision rights. This is a visual analogy, not a claim about a particular operating model. Credit: Jon Tyson / Unsplash.

Governance is a service, not a gate

Consider two possible experiences for a product designer who needs a more complex table-selection pattern.

In the first organization, the designer opens a vague request form, receives no acknowledgement, and is told three weeks later that the pattern is out of scope. The team has already built its own solution. The system group calls this a compliance failure. The product group calls it getting the work done.

In the second organization, the designer finds a clear contribution route. Within a few working days, someone helps determine whether an existing pattern can be extended, whether the problem belongs to a local product, or whether a shared pattern is justified. The team can continue with a documented temporary solution while a reusable change is evaluated.

The second organization still has standards. It simply makes the path through them usable.

That distinction matters because governance is experienced as a product. Its users are designers, engineers, product managers, content specialists and accessibility experts. They have jobs to finish, constraints to navigate and little patience for opaque processes.

Start with decision rights, not an org chart

The first question is not whether your design system should be centralized or federated. It is: which decisions must remain consistent across products, and which decisions should stay close to the product team?

For a multi-product enterprise, I would usually separate three levels.

1. The shared foundation

The core system team owns decisions whose inconsistency would create widespread cost: foundational tokens, accessibility baselines, core components, naming conventions, release policies and the rules for breaking changes. Product teams can propose changes, but no individual squad should silently redefine the meaning of a shared button, dialog or status.

2. Shared product patterns

Some problems are too complex for a primitive component and too common to remain local. Think advanced filtering, bulk actions, permissions, multi-step approval, data tables and error recovery. These patterns benefit from joint ownership: the system team maintains consistency while domain teams bring real use cases and evidence.

3. Local product experiences

A specialist workflow used by one product may not belong in the global library. Its team should have room to solve the problem without asking permission for every interaction detail, provided it uses the shared foundations and documents intentional exceptions.

The practical rule is to centralize the things that should not diverge and federate the knowledge that cannot be understood from the center.

A component has an inspectable example and a review mechanism. Storybook’s published visual-testing example. Credit: Storybook.

Do not confuse this with giving everyone equal authority over every change. A federated model still needs named maintainers, technical review and a clear final decision-maker. Without that, “community ownership” becomes a polite name for nobody being accountable.

Build an intake process that solves the requester’s problem

Many contribution forms ask for the proposed component name, variants, dimensions and visual references. That is useful later. It is a poor starting point because it assumes the requester has already chosen the correct solution.

I would begin with five questions:

1. What user or product problem are you trying to solve?
2. Where does it occur, and how frequently?
3. What have you tried with existing components or patterns?
4. What constraints make those options insufficient?
5. Which teams or products might face the same problem?

Those answers let the system team distinguish four very different requests.

A defect or documentation gap should be handled as maintenance. A small extension may fit within an existing component API. A repeated interaction problem may justify a shared pattern. A truly local requirement may be better solved in the product, with an exception recorded rather than a new global component created.

This is also where the system team can say “not yet” without leaving people stranded. A rejection should explain the reason, the available alternative and what evidence would change the decision.

Make ownership explicit before discussing component requests. This matrix is an illustrative operating model. Credit: Original editorial visual prepared for Andrea Mabellini.

Public design systems provide useful examples of different approaches. Atlassian Design explicitly distinguishes small fixes from major enhancements requiring system-wide coordination. The U.S. Web Design System invites bug reports, enhancements and component proposals through a visible contribution route. Neither model should be copied mechanically, but both make a critical point: the contribution boundary should be explained.

Use a lifecycle instead of treating publication as the finish line

A component is not “done” when it appears in Figma. It has a lifecycle, and the team needs to communicate its maturity.

I prefer a small set of meaningful stages:

1. Proposed: a problem and potential shared need have been documented.
2. Incubating: the solution is being tried in real product contexts and may change.
3. Stable: design, code, documentation and accessibility expectations are aligned.
4. Deprecated: teams should stop adopting it; a migration path is available.
5. Retired: the old option is removed after an agreed transition.

Every stage should have entry and exit criteria. For example, an incubating pattern might require use in two distinct workflows before the team decides it is genuinely reusable. That is an illustrative policy, not a universal threshold. The right bar depends on risk and product diversity.

Stability also needs a specific meaning. Does it guarantee API compatibility? Does it mean the Figma component and code implementation are aligned? Are keyboard behavior and screen-reader semantics documented? Can a product team rely on it without direct support?

The USWDS component lifecycle is a particularly useful reference because it makes proposal, maturity and retirement explicit. The important lesson is not the exact labels; it is that consumers can see how much confidence to place in a component.

Shared practices are discussed and maintained by people. An external workshop photograph, not Andrea’s client work. Credit: MING Labs / Unsplash.

Define what a contribution must contain

A contribution template should be proportionate to the change. Fixing a typo should not require the same evidence as introducing a new data-grid interaction.

For a shared component or pattern, however, I would expect a minimum evidence package:

• Problem: a short explanation of the user need and affected workflows.
• Reuse: evidence that the need exists beyond one screen or product.
• Design: key states, responsive behavior, content rules and composition constraints.
• Accessibility: keyboard, focus, semantics, contrast and relevant assistive-technology considerations.
• Engineering: API proposal, dependency impact and compatibility considerations.
• Documentation: when to use it, when not to use it, examples and known limitations.
• Ownership: who will maintain the contribution after it ships.

That last item is easy to miss. A product team may be happy to contribute a component once. It may not be able to maintain that component for three years. The system team needs to make the maintenance contract explicit before accepting the work.

Make exceptions visible and temporary

Every enterprise product has legitimate exceptions. Healthcare, banking and internal operations tools often contain interactions that a generic system does not anticipate. Treating every exception as a failure encourages teams to hide them.

I would keep a lightweight exception register with the product, affected pattern, reason, owner, review date and planned resolution. Not every exception needs to become a central backlog item. But the register helps distinguish an isolated domain requirement from a repeated gap in the system.

For example, three teams independently building a dense permission matrix is not three isolated exceptions. It is evidence that the system may be missing a reusable interaction pattern.

Conversely, one specialist clinical workflow should not force every product to adopt a complex component it will never need.

The objective is not zero exceptions. It is intentional variation rather than accidental drift.

Documentation should reduce support demand

Teams often document what a component looks like and forget to document how to make a decision with it.

For a mature system, I would prioritize usage guidance over exhaustive screenshots. A useful component page answers: What problem does it solve? When should I use it? What are the alternatives? What are the dangerous combinations? What does it do when data is missing? Which accessibility rules matter? What changed recently?

Then give teams a short onboarding path. A new designer should not need a guided tour of the entire documentation site to discover how requests work, where patterns live and who can help.

The zeroheight report also highlights communication and community as recurring concerns. Documentation alone is not communication, but well-structured documentation reduces the number of questions that need a meeting. Office hours and critique sessions can then focus on unresolved problems rather than repeatedly explaining where the button library is.

Give the system a predictable operating rhythm

Governance becomes credible when teams know what happens next.

A practical cadence might look like this:

• Weekly triage: classify new requests, identify blockers and assign owners.
• Biweekly pattern review: discuss higher-impact contributions with design and engineering.
• Monthly release: publish meaningful changes with migration notes and examples.
• Monthly office hours: help teams solve real product problems before they invent workarounds.
• Quarterly health review: examine adoption, exceptions, maintenance debt and roadmap trade-offs.

These are starting points, not ceremonial meetings to add automatically. A small team may combine several rituals. A large regulated organization may need more formal release controls. What matters is that each ritual has a decision to make and an output people can find afterward.

It also helps to publish a service expectation. For example: acknowledge requests within two working days; classify them within five; give high-impact proposals an explicit review date. Those numbers are illustrative. The useful property is predictability, not a heroic promise that a small system team cannot sustain.

Measure the system as an operating service

A dashboard full of component counts is not evidence of success. Fifty new components may mean the system is growing, or it may mean teams are solving the same problem in fifty slightly different ways.

I would organize measurement into four questions.

Coverage: can teams solve the problems they actually have?

Look at high-frequency product needs, not the total size of the library. Which common patterns are supported? Where are local exceptions clustering? Which requests recur? A missing table pattern may matter more than ten missing decorative components.

Adoption: are the approved solutions used in real products?

Measure code usage where possible, not only Figma instances. The two can diverge. Define the denominator carefully: adoption across all products is different from adoption across products that actually need the pattern. A percentage without that context can be misleading.

Friction: how difficult is it to work with the system?

Track request acknowledgement, time to decision, time to release, unresolved questions and repeated workarounds. A system can have high compliance and still be painful to use.

Health: can the team maintain what it has promised?

Review documentation freshness, accessibility issues, design-to-code parity, breaking changes and deprecated components still in use. This is where technical and design debt become visible before they cause expensive migrations.

GitHub’s published status vocabulary illustrates distinct states. These are issue states, not a design-system maturity score. Credit: GitHub.

The 2026 zeroheight report notes that teams use a mixture of design analytics, code usage, accessibility and delivery measures. That variety is not a problem. The problem is selecting metrics because they are easy to count rather than because they help make decisions.

For a small system team, one useful measure in each category is enough to start. Add more only when the first four change what the team prioritizes.

What changes when AI generates interfaces?

AI-assisted prototyping and code generation make governance more important, not less. A tool can create ten local versions of a component before anyone notices. It can also reuse the approved system more consistently if it has access to clear components, APIs, tokens and usage rules.

The governing principle stays the same: the approved path should be easier than the unofficial one.

In practice, that means making documentation structured enough for both people and tools; connecting design components to code equivalents; defining semantic variants rather than ambiguous visual names; and reviewing generated changes against the same contribution and release rules as human-written changes.

An AI-generated component should not be promoted to the shared library simply because it looks polished. It still needs evidence of reuse, accessibility review, engineering ownership and a lifecycle plan.

This is a different topic from making a system machine-readable. Machine readability is infrastructure. Governance decides which changes are allowed to become shared infrastructure.

A realistic example: three teams need better bulk actions

Imagine a hypothetical SaaS organization with a customer operations product, a billing product and an internal compliance tool. Each team has built a table with multi-row selection. Each has also invented a different way to confirm a destructive bulk action.

The system team could respond by standardizing the toolbar visuals and declaring the problem solved. That would be too shallow. The real shared problem includes selection persistence, permission checks, confirmation language, partial success and recovery when some records fail.

Here is how I would run the contribution:

1. Collect one real workflow from each product, including failure and permission states.
2. Identify what is truly common: selection model, action affordance, confirmation, result summary.
3. Keep domain-specific business rules outside the shared pattern.
4. Prototype the common behavior in two different contexts.
5. Review accessibility and engineering implementation before declaring it stable.
6. Publish a pattern with examples, constraints and a migration recommendation.
7. Check whether product teams adopt it and whether support questions decrease.

That is governance creating product value. It reduces divergent behavior while preserving domain-specific needs. The result is not simply a new component; it is a more predictable interaction across products.

A 90-day plan for teams starting from a component library

You do not need to reorganize the company to improve governance. Start with the smallest operating model that solves visible friction.

Days 1–15: map the current reality

Interview a handful of designers and engineers. Review recent requests, duplicate patterns, undocumented exceptions and the components that cause the most support questions. Identify where decisions are currently made and where they disappear.

Days 16–30: establish the rules

Define ownership for foundations, shared patterns and local experiences. Publish a simple intake template, triage categories, lifecycle stages and a clear place to ask for help. Make the initial rules short enough that teams will read them.

Days 31–60: pilot one contribution

Choose a recurring, painful pattern rather than a glamorous new component. Run it through the new process. Document how long decisions took, what evidence was missing and where review became a bottleneck. Adjust the process while the example is still fresh.

Days 61–90: publish, measure and refine

Release the pattern with usable documentation and migration guidance. Establish a regular communication rhythm. Review four starter measures: coverage gap, adoption, request friction and maintenance health. Publish what changed because of the pilot.

A pilot tests the operating model through an actual contribution. The ninety-day timing is an illustrative proposal. Credit: Original editorial visual prepared for Andrea Mabellini.

At the end of 90 days, the team does not need a perfect governance framework. It needs evidence that a shared product problem can move from request to decision to reusable release without disappearing into a queue.

Five governance mistakes worth avoiding

Building a committee before defining decision rights. More reviewers do not automatically create better decisions. Give each review a purpose and one accountable owner.

Measuring Figma adoption as if it were production adoption. A design library can look healthy while the live product remains inconsistent. Inspect the implementation.

Making contribution harder than duplication. Teams respond to incentives. If a local workaround takes an afternoon and a shared request takes a quarter, the process has already chosen the outcome.

Promoting every local pattern to the core library. Reuse should be demonstrated, not assumed. A smaller coherent system can be more valuable than a comprehensive but contradictory one.

Publishing without migration and communication. A breaking change that nobody understands is not successful governance, even if the new component is technically superior.

The governance checklist I would use in a review

• Can any product team identify the owner of a shared decision?
• Can a requester explain the problem without designing the solution first?
• Does every request receive a clear outcome and next step?
• Are foundations, shared patterns and local experiences governed differently?
• Are contribution requirements proportional to risk?
• Can teams see whether a component is experimental, stable or deprecated?
• Are accessibility and engineering review built into the lifecycle?
• Are legitimate exceptions documented and revisited?
• Does documentation help teams decide, not just copy?
• Are releases and migrations communicated predictably?
• Do adoption metrics reflect real product usage?
• Does the process get faster as the system learns?

The point of governance is better product decisions

Design system governance should not be judged by how many rules it produces. It should be judged by what those rules make possible.

A good operating model lets a product team move quickly without reinventing common interactions. It lets the system team protect accessibility and consistency without becoming an approval bottleneck. It makes contributions welcome but not arbitrary. And it gives leaders a credible way to understand whether investment in shared infrastructure is paying off.

The library is the visible artifact. Governance is the set of decisions, relationships and feedback loops that keep it useful.

When those loops work, teams stop asking whether they are “allowed” to use the design system. They use it because it is the most reliable way to deliver a better product.

Related reading: why design systems need clearer structure and documentation for AI; connecting Figma components to real code with MCP; the invisible leadership work behind effective product teams; interaction patterns that make autonomous product behavior trustworthy.