Why Your Design System Will Die (And It’s Not a Technical Problem)

A GitHub repository with dozens of components, a well-organized Storybook, carefully named tokens. And nobody really using it. I contributed to one. I watched it go to sleep. What took me a while to understand is that the problem wasn’t in the code.

The Decision Nobody Made

Our design system was built for one application. A single one. With its own constraints, its own visual identity, its own specific use cases. It did what it was built for — quite well, actually.

The problem came when we tried to extend it to other products. Products that hadn’t been designed with it in mind, that had their own UI logic, their own trade-offs. We tried to fit different contexts into a mold built for just one.

Nobody had asked the fundamental question upfront: for whom, exactly? Not “for which stack”, not “with which documentation tool” — for which product family, with what shared identity, within what organizational scope. That question doesn’t belong to a single developer. It belongs to a product, design, and engineering decision made together. Since that decision was never clearly made, the design system inherited a blurry scope by default.

The Warning Sign: The First Silent Exception

A design system doesn’t die all at once. It unravels through an accumulation of small workarounds that nobody documents.

The first sign is the component created “just for this project” without anyone raising their hand. No ticket, no team discussion, no “does this deserve to go into the DS or not?”. Just a file that appears in a project-specific components/ folder and solves today's problem.

The second sign is the designer who delivers a mockup with a button that doesn’t exist in the DS. Not out of bad faith — because they had a client constraint, a tight deadline, and nobody to ask “do we evolve the DS or create an exception?”. So the PR gets merged, nobody comments, and the exception quietly becomes the norm.

This isn’t an individual discipline problem. It’s the symptom of a missing mandate: nobody explicitly holds the role of arbitrating these decisions. Who decides whether a component enters the DS? Who has the authority to say no to an unplanned variant? When that role doesn’t exist, the default answer is always “create it locally and we’ll figure it out later”. And later never comes.

The Shadow Design System Being Built in Silence

What nobody sees coming is that exceptions don’t stay isolated. They pile up, get copied from one project to the next, and eventually form their own parallel system — undocumented, unmaintained, but very real.

A ButtonPrimary in the DS. A ButtonCustom in project A. An ActionButton in project B. Three implementations of the same concept, with three slightly different behaviors, three separate style sets to maintain. Every developer who joins a new project starts from what they find locally rather than what's in the DS — because it's faster, because the DS doesn't cover their case, because they don't know who to ask.

The official DS is asleep. The shadow DS is alive and well. It grows in the corners.

Figma Isn’t the Solution, But It’s a Good Diagnostic Tool

When design systems come up, Figma enters the conversation quickly. For good reason — used properly, it can become the shared source of truth between design and engineering, the place where a decision about a component is visible to everyone in real time.

Figma variables and published libraries are a step in the right direction. When a designer publishes a component update through the shared library, every file that depends on it gets a notification. It’s a workflow that enforces a form of discipline: modifying a component becomes an explicit act, not a silent workaround.

But Figma doesn’t solve the mandate problem — it just makes it more visible. If nobody owns the responsibility of publishing library updates, they won’t get published. If designers each work in their own file without connecting to the shared library, Figma becomes just another tool gathering dust. The tool doesn’t create governance. It can only support it — or reveal its absence.

What Figma does enable is making the contract between design and dev tangible. A color variable named color/primary/default in Figma that maps exactly to a CSS token of the same name in the codebase — that's a visible, traceable agreement that's hard to quietly work around. It's an organizational anchor as much as a technical one.

What Abandonment Really Reveals

An abandoned design system isn’t a technical execution failure. It’s an X-ray of the organization at the moment it was launched.

In our case, the DS was started with good intentions and real energy. But it had been framed as a deliverable — something you build, ship, and document — rather than as an ongoing practice that requires an owner, a collectively agreed-upon scope, and the ability to say no when a product steps outside the boundaries.

For a Tech Lead, this is a signal worth catching early. If you’re maintaining a DS or thinking about launching one, the technical question is the last one to ask. Before choosing between Storybook and Chromatic, before debating token architecture, make sure someone on the team explicitly owns the responsibility of keeping that system alive — and has the authority to arbitrate when edge cases show up. Because they always do.

If your design system is starting to gather dust, before rethinking the architecture or migrating to a new tool, ask yourself a simpler question: who in your organization has the mandate to keep it alive? If the answer is unclear, the problem isn’t in the code.