Why Most Design Systems Die in a Figma File (And How to Fix That)
3 min read
I've built component libraries for SaaS products, a healthcare platform, and a sales- intelligence tool — and I've inherited the wreckage of several that died. The pattern is always the same: months of work produce a beautiful system, there's a launch presentation, and six months later product teams are still hand-styling buttons. The Figma file is immaculate. The codebase never heard about it.
Design systems don't fail because the components are bad. They fail for three organizational reasons, each with a practical fix.
Reason 1: Built in isolation from real screens
The failure mode: a dedicated team builds "the system" as a separate project — abstract components designed for hypothetical usage, polished in Storybook, disconnected from any shipping screen. When product teams finally try them, the components don't fit. The card doesn't support the layout the dashboard actually needs; the modal can't do the one weird thing checkout requires. Teams work around the system once, and workarounds are habit-forming.
The fix: extract, don't invent. Build the system from the product, not beside it. The component library that stuck at ZenBee started as the three components duplicated most often across real screens — extracted, hardened, and swapped back in. Every component earned its place by replacing existing duplication, which meant it fit real usage by construction. A design system is a refactoring, not a greenfield project.
Reason 2: No clear ownership
The failure mode: the system launches, its creators rotate back to product work, and now a pull request against the button component sits unreviewed for three weeks. Teams learn that depending on the system means being blocked by it, so they fork components locally "just for now." Entropy does the rest.
The fix: name an owner and fund maintenance. Not a committee — a person (or a small rotating pair) whose sprint capacity explicitly includes the system, with an SLA teams can rely on: contribution PRs reviewed within two days, questions answered same day. The moment consuming teams trust that the system responds faster than a local fork, forking stops. Ownership is what separates a system from a snapshot.
Reason 3: Too rigid for edge cases
The failure mode: the system's components are sealed boxes. The first time a product team needs a variant the system doesn't offer — a destructive button with an icon, a card without padding — they face a choice: file a request and wait, or copy the CSS and move on. They copy the CSS. Every rigid component is a future defection.
The fix: design escape hatches on purpose. Good systems have layers: tokens (colors,
spacing, type) → primitives (unstyled behavior) → styled components. When the styled
component doesn't fit, teams should be able to drop one layer down and compose the
primitive with system tokens — staying inside the system's vocabulary instead of leaving
it entirely. A className prop is not a design-system failure; it's a pressure valve
that keeps deviations visible and consistent. (Tokens are the foundation layer here —
I've written a dedicated explainer on design tokens.)
What actually drives adoption
Notice what none of the fixes involve: better components. Adoption is driven by economics from the consumer's perspective. A product engineer adopts the system when using it is faster than not using it — this sprint, not "eventually." That means: excellent defaults, five-minute setup, examples for the ten most common screens, and a human who answers questions quickly. Every adoption success I've seen came down to the system being the lazy path.
A starting checklist
- Extract your first components from real, duplicated UI — not from imagination.
- Start small: tokens + the five most-duplicated components. Ship, then grow.
- Name an owner with real allocated time and a review SLA.
- Layer the system (tokens → primitives → components) so edge cases have a sanctioned path.
- Measure adoption (imports of system components vs local ones) — it tells you the truth the launch deck won't.
The design system that wins isn't the most complete one. It's the one that's alive.