Your Design System Has No Owner — That's Why It's Quietly Dying
The Figma library is maintained. The documentation exists. The component inventory is complete. Somewhere, a Notion page explains how to contribute.
The design system is still falling apart.
Not in any dramatic way. It's subtler than that. Components get forked instead of updated because getting an update approved takes longer than shipping the thing. The button in the marketing site doesn't match the button in the product. The team that joined nine months ago is using their own variant of the card component because the original didn't do what they needed, and nobody ever officially reviewed whether the gap should be in the component or the use case.
The components aren't the problem. The governance is.
What Governance Actually Means
"Governance" is one of those words that makes designers' eyes glaze over. It sounds like bureaucracy. Like the thing that happens before you're allowed to do the interesting work.
What it actually means, stripped of the jargon: who decides what goes in, who has authority to say no, and what happens when the system and the product team want different things.
That's it. Three questions. Most design systems have vague, incomplete, or entirely absent answers to all three.
The consequence is predictable: without clear authority, decisions default to whoever has the most social capital in the room, or whoever moved fastest, or nobody — leaving a gap that gets filled by individual contributors making local decisions that compound into systemic inconsistency.
Why the Component Phase Gets More Attention Than the Decision Phase
The initial work of building a design system is compelling in a way that governance isn't. You get to make decisions — what goes in, how it looks, how it behaves. You produce artifacts. You can see the system taking shape. The feedback loop is tight and satisfying.
Governance is the opposite. It's mostly about what doesn't happen: components that don't get silently forked, conflicts that get resolved before they compound, requests that get evaluated against system principles rather than individual preferences. The evidence that it's working is largely negative space — the incidents that don't occur.
This is why design systems often invest heavily in the documentation and component phases and underinvest in defining decision-making structure. The documentation is visible and demonstrably good. The governance is invisible when it works and only visible when it fails.
By the time it fails conspicuously enough to demand attention, there's usually a year's worth of inconsistencies to untangle.
The Three Questions That Don't Get Answered
Who approves changes to the system? The honest answer at most organizations is: it depends, and often it's unclear. A senior designer? The design system team, if one exists? Product leadership? The answer matters because every component change affects downstream consumers. Without clear approval authority, the path of least resistance is to quietly fork rather than formally request — and forks are how systems die slowly.
Who resolves conflicts between product needs and system coherence? This is the hard one. Product teams have real pressures: ship dates, feature requirements, specific use cases the system wasn't designed for. The design system has coherence requirements: consistency, accessibility, maintainability. These genuinely conflict. When a product team needs a component variant that doesn't exist, someone has to decide whether to add it to the system, build it as a one-off, or redesign the use case to fit what exists. That's not a design decision. It's a prioritization and authority decision. Leaving it unaddressed produces exactly the proliferation of variants that makes the system harder to maintain over time.
Who owns deprecation? Components age out. Patterns that made sense two years ago conflict with directions the product is moving. Deprecated components that still live in the codebase get used anyway, either because teams don't know they're deprecated or because the path to the replacement is unclear. Without an explicit owner for deprecation — including communications planning, migration support, and enforcement — old components don't actually go away. They just become a shadow system running alongside the official one.
The Shape Governance Can Take
I want to be specific because "figure out your governance" is not useful advice.
The minimum viable governance structure for a design system is:
- A decision authority — a named person or small group with explicit authority to approve changes, resolve conflicts, and make system-level calls. This can be the design system team, a design lead, or a council if the system serves multiple product areas. What it cannot be is ambiguous.
- A contribution process — a defined path for how teams with needs that don't exist in the system can request additions or changes. The process should have a response commitment (not an approval commitment, but a commitment to say yes, no, or here's what we'd need to consider this within a defined period).
- An escalation path — what happens when product needs and system coherence genuinely conflict and the parties can't resolve it themselves. Who has the final call, and what criteria should govern it?
This doesn't require a formal committee structure or a new headcount. It requires names in boxes and agreements that those names correspond to real authority.
The research on why design systems fail consistently points to this gap. A 2026 analysis by Figma's community team of design systems at mid-scale organizations found governance absence — not component quality, not tooling, not documentation — as the most consistent predictor of system entropy over a two-year horizon. The systems that stayed healthy had clear ownership. The ones that didn't had extensive libraries and unclear authority.
The Uncomfortable Version
There's a reason design systems often avoid governance conversations: they require organizational decisions that go above the design team.
Clarifying who has authority to resolve product-vs-system conflicts is a conversation that involves product management, sometimes engineering, sometimes executives. It requires someone with organizational standing to get those conversations on the calendar and take them to a conclusion.
This is harder than designing a better button. It requires different skills, different relationships, different kinds of influence than the craft work that most design system contributors were hired for.
But it's the actual work. The component inventory isn't the problem. The research participants who only agree with you can't tell you your governance is broken — they'll validate whatever system you show them. Real-world entropy over time tells you.
Your design system doesn't need better documentation. It needs a person with authority to say no.
Photo: ThisIsEngineering / Pexels