We inherited a project with a "design system." I open Figma and there it is, a tidy library: buttons, cards, color tokens, everything neatly arranged. Then I open the code. Three different implementations of the primary button, two with hardcoded hex values that don't even exist in the tokens. Six months earlier someone had updated the radius in Figma from 8px to 6px. In the code it stayed 8px in 40 places. Nobody noticed, because nobody was responsible for noticing.

That wasn't a design system. It was a Figma library everyone called a design system. The difference between those two costs more than you think, and that exact difference is why most design systems quietly die within their first year.

A Figma library is not a system

A library is an artifact. A system is a process. That sounds like a platitude until you see how it plays out in practice.

A Figma file full of components is a snapshot of decisions made at one point in time. It's beautiful on the day it's built. The problem is that the product keeps living and the file doesn't. A new developer needs a dropdown that isn't in the library, so they build their own. A designer on another project needs a card variant, so they "quickly" spin one up outside the system. Marketing wants a landing page with a slightly different button, and there it goes.

None of those decisions is wrong on its own. The problem is that nobody decides how those decisions flow back into the system, or whether they flow back at all. Six months later you have a Figma that says one thing, code that does another, and three teams all working "off the design system" while none of them are working off the same one.

A design system is not a set of components. It's an agreement about who makes decisions, who owns quality, and how a new pattern enters the system. Without that agreement, the components are just scenery.

So why does it fail, even when everyone says they love it

The most common misdiagnosis is that the system fails because the components aren't good enough, or because people don't like consistency. That's not it. People like consistency. What they don't like is friction.

A system dies from low adoption, and adoption drops for mundane reasons:

• Nobody maintains it. It was built as a project, not a product. The team that assembled it moved on to the next sprint, and the system froze at its launch moment.
• There's no clear owner. When the question "is this button allowed to be used this way?" comes up, there's no one to ask. So the developer decides alone, and that decision never makes it back into the system.
• Contributing is harder than working around it. If it's faster to write your own component than to go through the process of adding one to the system, people will write their own. Every time.
• There's no metric. Nobody measures what percentage of the UI actually uses the system, so nobody notices when that percentage starts sliding.

These are all governance problems, not design problems. And governance is exactly what a Figma library, by definition, doesn't have.

A system is a product, and a product has a cost

Here's the part that usually gets glossed over when someone's selling the idea of a design system. It isn't free, neither to build nor to maintain.

Real numbers for a serious system: the initial build of a token set and component library costs roughly $80k to $300k, depending on whether you're doing web-only or native platforms too. Maintenance then requires 0.5 to 1.0 of a full-time employee, which annually lands somewhere between $90k and $250k once you factor in CI, visual-test hosting, and the registry.

Those numbers look scary until you put them next to the cost of the alternative. A team with three product squads or five-plus frontend engineers spends $600k to $2M a year on UI work. Cutting that by 15 to 25 percent is serious money. But, and this is the crux, that saving only materializes at 60 to 80 percent adoption across the product. Below that, the system is pure cost with no return.

Translated: a design system pays back within 12 to 24 months, but only if it's actually used. And it's only used if someone maintains it. And it's only maintained if it has an owner and a budget. See the pattern? Everything hangs on governance, not on components.

What a system that doesn't die looks like

The difference between a library and a system is operational, not visual. Here's what actually changes the outcome:

An owner with a name. Not "the design team," but a specific person whose job is to keep the system alive. A principal engineer or staff designer, 50 to 100 percent of their time. If you can't afford that, you can't afford a system, you can afford a library.

Contribution rules. A clear path for how a new component enters: who proposes, who approves, who documents. Contributing has to be easier than working around it, or it won't happen.

Deprecation as a process. Components die. A system with no way to remove the old is as dangerous as one that can't add the new. Without it you pile up dead code nobody's allowed to touch.

Adoption metrics. Measure the percentage of shipped UIs that use the system. Target: 50 percent at six months, 70 percent at a year. If you don't measure, you don't know you're sinking until it's too late.

The system as part of engineering scope, not a marketing add-on. Shopify (Polaris), Atlassian, Stripe, they all treat system docs and examples as part of the shipped product, not as something you do if there's time left over. There's never time left over.

The point

If you take one thing from this post, make it this: a Figma library is a starting point, not a destination. A beautiful file full of components is a necessary condition, but far from a sufficient one.

A system with no owner, no rules, and no metric is not a system. It's a snapshot that looks great in a demo and falls apart in silence over the next six months, component by component, until one day you inherit a project with three different implementations of the primary button and realize the "design system" only exists on paper.

If you're building a design system, the first question isn't "which components do we need." The first question is "who's going to maintain this a year from now, and is there a budget for it." If you don't have an answer to that, you're not building a system. You're building a pretty Figma file that will die by spring.

Related:

• We Stopped Chasing Design Trends. Here's Why Your Site Benefits
• AI Personalization Sounds Great. Your Users Might Hate It

Building a design system that needs to outlive a single sprint? Get in touch and we'll set it up as a product, not a file.