Why 41% of design systems get abandoned

Knapsack's 2024 Design Systems Maturity Report contains a number that should be more famous than it is: 41% of design systems launched in the previous two years were no longer actively maintained.

Not deprecated. Not replaced. Just… abandoned. Still in the repo, still nominally the system, quietly no longer true.

The instinct is to assume those systems were bad — poorly built, wrong abstractions, a team that didn't know what it was doing. Mostly they weren't. The components were fine. What failed came after: nobody owned it, there was no path to contribute to it, changes weren't traceable. The system drifted from the design source, developers stopped trusting it, and once developers stop trusting a component library they stop using it — which is the actual death, and it's silent.

What drift looks like from the inside

It rarely arrives as a crisis. It arrives as a daily choice.

A developer opens the library, finds a component that doesn't quite match the current design, and has to decide: use the stale component, or rebuild the UI from scratch. Both answers are bad. The first ships something wrong. The second creates a second source of truth — and now there are two buttons, and next quarter there will be five.

Nobody escalates this. It's a small decision, made under deadline, dozens of times, by people who each individually made the reasonable call. That's what makes it so effective at destroying systems.

The tools only handle mechanics

There is now a healthy market of tools that connect Figma to code — token pipelines, Code Connect, AI agents that read a design file and emit a component. I use them. They work.

They also do not solve this problem, and it's worth being precise about why: every one of them addresses generation, and drift is not a generation problem. Generation is a one-time cost. Drift is a recurring one. A tool that makes it faster to build the system does nothing about the forces that pull it apart afterward — and may even accelerate them, because it's now cheap to generate a competing version of the button.

Look at what the mature systems actually have in common. Atlassian, Shopify Polaris, eBay, GOV.UK — the differentiator isn't tooling. It's three unglamorous things:

• A named owner. One accountable person, not a committee and not "the design team."
• A documented contribution path. Anyone can propose a change; there are fixed criteria for accepting it.
• Semantic versioning and a changelog. Changes are traceable, so trust is recoverable when something breaks.

None of that is a tool. All of it is governance.

The ownership finding

Sparkbox's 2024 survey found teams with a dedicated design system owner reported 2.5× higher satisfaction than teams with distributed ownership — regardless of team size.

That last clause is the useful part. The usual objection to naming an owner is scale: Atlassian's design system team is 18 people, and you have zero. So you distribute ownership across the design team, which feels egalitarian and collaborative and is, in practice, the thing most correlated with the system rotting.

Distributed ownership is not lightweight governance. It's the absence of governance with a nicer name. When everyone owns the naming convention, the naming convention drifts — not because anyone is careless, but because there's no one whose job it is to say no.

The finding says you don't need 18 people. You need one accountable person. That's a headcount conversation almost any organization can win.

What I'd tell a team starting a migration today

Build the governance layer first, not last. It costs a week. It is the entire difference between a system and a component library that will be abandoned by 2028. Every team that skipped it intended to come back to it.

Fix naming at the source. When Figma layer names don't match code conventions, generated code drifts immediately — and so does hand-written code. That's the tell that this was never an AI problem. Fixing it once in the design file is cheaper than correcting it downstream forever.

Treat developer trust as the metric. Not component count, not coverage. The question that predicts survival is: when a developer needs a button, do they reach for yours? Everything else is a proxy.

Make contribution possible. A system that only its owner can change becomes a bottleneck, and bottlenecks get routed around. Atlassian's two-way model — anyone proposes, one person reviews against fixed criteria — is the balance worth copying.

The uncomfortable conclusion is that design systems are not really a design problem or an engineering problem. They're an organizational one wearing a component library as a disguise. The tooling has gotten extraordinary. The abandonment rate hasn't moved.

That should tell us where the work is.

Sources: Knapsack, 2024 Design Systems Maturity Report. Sparkbox, 2024 Design Systems Survey.