Design system governance: who owns what and how decisions get made

Why do design systems die?

This article is part of our complete guide to Design Systems. Start there for the big picture.

A 2024 report by Knapsack found that 41% of design systems launched in the previous two years were no longer actively maintained (Knapsack, 2024). The cause isn’t bad components or ugly tokens. It’s the absence of governance.

I’ve watched this pattern repeat across multiple organizations over 20 years of design work. A team gets excited, builds a beautiful component library, launches it with fanfare, and moves on to the next project. Six months later the Figma library is out of sync with the codebase. Engineers have forked components because nobody was approving their pull requests. New designers don’t even know the system exists.

The system didn’t fail because it was poorly built. It failed because nobody was responsible for keeping it alive.

The longest-surviving design system I’ve worked on wasn’t the most sophisticated. It was the one where we assigned a clear owner on day one and scheduled monthly reviews before we’d even finished the first batch of components. Governance came first. The system followed.

What ownership model works best?

The 2024 Design Systems Survey by Sparkbox found that teams with a dedicated design system group reported 2.5x higher satisfaction scores than those relying on distributed ownership (Sparkbox, 2024). Ownership isn’t about control. It’s about accountability. Someone has to wake up every morning knowing the system is their job.

Dedicated team

This is the gold standard. A team of two to four people whose primary responsibility is the design system. At minimum you want one designer, one developer, and ideally a product manager who treats the system as their product. They manage the backlog, review contributions, publish releases, and track adoption.

Large organizations like Shopify, Atlassian, and IBM all run dedicated design system teams. There’s a reason. When the system competes with feature work for someone’s time, feature work wins every single sprint. A dedicated team removes that conflict.

The challenge? Convincing leadership to fund what looks like infrastructure. I’ve found the strongest argument is time savings. If your product team has 40 engineers and each one wastes two hours a month rebuilding things the system should provide, that’s 80 hours of lost productivity. A two-person dedicated team pays for itself almost immediately.

Rotating stewardship

Not every company can justify a full-time team. That’s fine. The next best option is rotating stewardship, where a team member takes ownership of the design system for a quarter at a time. They handle incoming proposals, schedule reviews, and keep documentation current.

I’ve used this model with teams as small as six people. The key is making the rotation formal. Put it on the team’s capacity plan. Block 20-30% of the steward’s time for system work. If it’s treated as a side hustle, it won’t get done.

The handoff between stewards matters too. Document ongoing decisions, open proposals, and known issues in a simple log. Without that context transfer, every new steward starts from scratch.

The “everybody owns it” trap

This sounds democratic. In practice it means nobody owns it. When ownership is shared equally across every team member, nobody feels personally responsible for reviewing proposals, updating documentation, or publishing releases. Decisions stall because there’s no tiebreaker.

I’ve seen this model attempted at three different companies. All three abandoned it within a year. The system drifted, components diverged, and teams quietly stopped contributing because nothing ever got reviewed.

If you hear “everyone owns the design system” in a planning meeting, translate it to “nobody owns the design system” and plan accordingly.

How should the contribution process work?

According to Figma’s 2023 survey, 63% of designers said unclear contribution guidelines were the top reason they built components outside the design system (Figma, 2023). Your contribution process has one job: make it easier to contribute to the system than to work around it.

The submission template

Every contribution should answer four questions. What problem does this solve? How many teams or users does it affect? What’s the proposed solution? And does a similar component or pattern already exist in the system?

Keep the template short. A Google Form or a GitHub issue template works. If submitting a proposal takes longer than 15 minutes, you’ve over-engineered the process. People won’t fill out a five-page document to suggest a new icon variant.

Review criteria

Not everything that gets proposed should make it into the system. You need clear criteria for what earns a spot. I use four filters.

Token compliance. Does the component use system tokens, or does it introduce hard-coded values? Hard-coded values break theming and create maintenance debt.

Accessibility. Does it meet WCAG 2.2 AA at minimum? Are ARIA roles defined? Does it work with a keyboard? Can a screen reader announce it correctly?

Documentation. Is the component documented with states, variants, usage guidelines, and “don’t use this for” guidance? Undocumented components are invisible components.

Naming. Does the naming follow existing conventions? A system with PrimaryButton, secondary-btn, and cta_button isn’t a system. It’s a mess.

Don’t leave contributors in limbo

This is where most contribution processes break down. Someone submits a proposal and hears nothing for six weeks. They lose interest. They build the one-off. Next time, they don’t bother proposing at all.

Set a maximum response window. In my experience, 10 business days works well. Acknowledge receipt immediately, provide initial feedback within a week, and make a final decision within two weeks. Even a “no, and here’s why” is better than silence. Contributors who feel heard will contribute again.

What review cadence keeps the system healthy?

Monthly reviews are the right cadence for most teams, according to the 2024 State of Design Systems report by Specify, which found that teams reviewing monthly had 34% fewer “zombie components” (components in the system that nobody uses) than those reviewing quarterly (Specify, 2024). Too frequent and you burn time in meetings. Too rare and proposals pile up.

What a good review meeting looks like

Block 60 to 90 minutes once a month. The agenda should cover three things and only three things.

Proposal triage. Walk through every open submission. Accept, reject, or request changes. Don’t defer decisions to “next month” unless genuinely blocked by missing information.

Conflict resolution. Two teams want the same component to behave differently? This is where you resolve it. The system owner has the final call, but hearing both sides in the same room prevents resentment.

Roadmap check. Is the system’s backlog still aligned with product needs? Are the right components being prioritized? Spend ten minutes here, not thirty.

Rapid growth adjustments

If your organization is scaling fast, hiring multiple teams, or launching new product lines, consider weekly syncs for a limited period. Keep them short. Thirty minutes, focused entirely on unblocking active contributions. Drop back to monthly once the pace stabilizes.

Treating the system as a product

Here’s the mindset shift that separates healthy systems from abandoned ones. Your design system has users (designers and developers). It has a backlog. It should have a roadmap. It needs regular releases.

Would you ship a product and never update it? Would you ignore user feedback for months? Of course not. Apply the same thinking to the system.

How should you handle versioning and releases?

Semantic versioning is the industry standard, used by 82% of mature design systems according to the 2024 Sparkbox survey (Sparkbox, 2024). It gives consuming teams a clear signal about what changed and whether they need to worry about it.

Semantic versioning in practice

The format is major.minor.patch. A patch release (1.0.1) means bug fixes. No API changes, no new behavior. Safe to update without testing.

A minor release (1.1.0) means new components or features. Existing components are untouched. Update when ready.

A major release (2.0.0) means breaking changes. Something your team relies on has changed in a way that might require code updates. Read the migration guide before upgrading.

Breaking changes need a migration path

Never ship a major version without a migration guide. Developers won’t upgrade if they can’t estimate the effort involved. Your guide should list every breaking change, show before-and-after code examples, and estimate the time needed for migration.

I’ve seen teams resist major versions entirely because past migrations were painful and undocumented. That’s a governance failure, not a technical one.

Changelogs people actually read

Most changelogs are unreadable walls of commit messages. Nobody benefits from “fixed stuff” or “updated component.” Write changelogs for humans. Group changes by category (added, changed, fixed, removed). Use plain language. Link to the relevant documentation for new components.

The best changelog practice I’ve adopted is a two-sentence summary at the top of every release. Something like: “This release adds the Drawer component and fixes a focus-trap bug in Modal. No breaking changes.” Busy developers read those two sentences. Some of them read nothing else. That’s okay.

How do you measure adoption?

Component coverage, the percentage of UI built with system components rather than one-offs, is the single most telling metric. According to Supernova’s 2024 benchmark report, organizations with over 70% component coverage shipped new features 40% faster than those below 50% (Supernova, 2024). Measure this first. Everything else follows.

Component coverage

Scan your codebase periodically. What percentage of UI elements come from the design system versus custom implementations? Tools like Omlet and design-system-detective can automate this. Below 50% means the system isn’t meeting teams’ needs. Between 50% and 70% is healthy but has room to grow. Above 70% is where speed gains become measurable.

Time-to-build

Compare how long it takes to build a new feature with the system versus without it. This is harder to measure precisely, but even rough estimates are useful. If a team says “we built the settings page in two days because the components were ready,” capture that. Those stories justify continued investment.

Support volume

Track how many questions the system team receives per sprint. A sudden spike might mean a confusing release or missing documentation. A steady decline usually means the docs are getting better. Zero questions might mean nobody’s using the system.

What low numbers tell you

Low adoption is a symptom, not a diagnosis. I’ve found it usually traces back to one of four root causes. The system is missing components that teams need, so they build their own. The documentation is hard to find or out of date. The developer experience (installation, imports, configuration) is painful. Or there’s no contribution process, so teams that need something different can’t get it into the system.

Don’t assume low adoption means people don’t want a design system. Ask them what’s not working. The answers are usually specific and fixable.

At one organization I worked with, adoption jumped from 38% to 71% in a single quarter after we addressed three things: we added a missing data table component, we moved docs from Notion to a searchable site, and we cut the npm install steps from six to two.

When should you deprecate components?

Deprecation is the part of governance that nobody wants to do. But a system that only grows and never prunes becomes bloated and confusing. According to the 2024 Sparkbox survey, 35% of design system teams reported having components in their system that no one was using (Sparkbox, 2024). Those zombie components add maintenance cost and confuse new team members.

When to deprecate versus when to update

If a component still solves the right problem but its implementation is outdated, update it. If the problem itself has changed or a better pattern has emerged, deprecate the old component and introduce the replacement.

A concrete example: you built a Tooltip component that uses hover triggers. Your product has since expanded to mobile. Hover doesn’t work on touch devices. The right move isn’t to patch Tooltip with touch workarounds. It’s to build a new Popover component that handles both contexts, then deprecate Tooltip.

The communication timeline

Deprecation needs three phases. First, announce the deprecation with the reason and the replacement component. Give teams at least one full release cycle to become aware. Second, mark the component as deprecated in code (console warnings) and in documentation (visible badges). Third, remove it in a future major version, never in a minor or patch release.

I’ve found that a minimum of three months between announcement and removal works for most organizations. Smaller teams with a single product can move faster. Enterprise environments with dozens of consuming teams might need six months.

Handling teams still using deprecated components

Some teams will ignore the deprecation notice. That’s reality. Don’t force-remove components while teams still depend on them. Instead, reach out directly. Ask what’s blocking migration. Sometimes it’s capacity. Sometimes the replacement doesn’t cover an edge case. Both are valuable signals.

How do you make the system the path of least resistance?

The ultimate test of governance isn’t documentation or process. It’s this question: is using the system easier than ignoring it? A 2023 survey by zeroheight found that design systems with dedicated documentation sites had a 72% adoption rate, compared to 31% for systems documented only in Figma files or wikis (zeroheight, 2023). Ease of access drives everything.

Developer experience is the adoption driver

Developers are your primary consumers. If the install process is confusing, if imports are verbose, if documentation is buried in a wiki nobody reads, adoption will stay low regardless of how good the components are.

Invest in a clean package structure. Provide copy-paste code snippets for every component. Build IDE plugins or snippets if you can. Maintain a dedicated Slack channel (or whatever your team uses) where people can ask questions and get fast answers.

Here’s something I rarely see discussed: the perceived cost of using the system versus the actual cost. Even if the system saves time overall, developers will avoid it if the initial setup feels heavy. I’ve seen adoption double after we reduced the “getting started” guide from a full page to five lines of code. First impressions matter, even for internal tools.

Celebrating contributions

Publicly acknowledge teams and individuals who contribute to the system. Mention them in release notes. Bring up their contributions in all-hands meetings. This isn’t just about being nice. It signals to the broader organization that contributing to the system is valued work, not a distraction from “real” work.

The ongoing test

Every quarter, ask yourself two questions. First: when a developer needs a button, is their first instinct to grab it from the system or to build one? Second: when a designer needs a new pattern, do they check the system first or start from a blank canvas?

If the answers aren’t what you want, the system’s governance needs work. Not the components. Not the tokens. The governance. Because governance is what makes the system feel alive, maintained, and worth trusting.