The graveyard is bigger than the success stories
If you survey design systems across the industry, the failure rate is striking. Two out of three teams that build a "design system" abandon it within eighteen months. The artefacts remain — a Figma library nobody opens, a Storybook nobody updates, a tokens repo whose last commit is from a former employee — but the system itself stops being used. Engineers go back to copying CSS from older components. Designers go back to redrawing buttons by hand. The system becomes a museum.
We have audited many of these graveyards. The failure modes rhyme. Below are the patterns we have seen and the rules we now follow on every system we ship.
Failure mode 1: the system is owned by nobody
The most consistent predictor of failure is shared ownership without a single accountable team. "It's a shared resource" sounds democratic but means "nobody fixes it when it breaks". The rule we now apply: a design system needs a Directly Responsible Individual. Not a committee. Not a Slack channel. One person whose name is on the README and whose performance review includes "is the system in active use".
Below the DRI, contributions can come from anyone. But a system without a single throat to choke is a system that drifts.
Failure mode 2: the system is a clone of another system
Teams that started with "let's just use Material Design" or "let's just clone Tailwind UI" rarely build durable systems. The clone has no opinions of its own; it is shaped by another company's product needs, not yours. Within six months your product needs diverge from the source, your team adds custom components on top, and the result is the worst of both worlds — a system that is opinionated and not yours.
The fix is not to write a system from scratch. The fix is to fork with intent. Pick a reference system, document the things you are keeping, the things you are changing, and the principles that drive the changes. The fork becomes yours the moment you write its principles down.
Failure mode 3: the system has no consumption story
Systems are often built before there is any product they would serve. Designers spec a button before any team has asked for one. Engineers ship a primitive component library before any application is using it. Six months in, the system has thirty components and zero adoption. People are not using it because no application depended on it during its construction.
We now flip this. The first three components in any new system are extracted from real product code, not designed in isolation. They are the components that already exist in two or more places in the codebase, that already need to converge. The system grows by consolidating working code, not by predicting future code.
Failure mode 4: the system has no version story
Software has versions; design systems often do not. When the team needs to ship a breaking change to a primitive (a colour rename, a spacing token shift), they either ship it instantly and break every consumer, or they refuse to ship it and the system calcifies. Both failure modes accelerate abandonment.
We now treat design system primitives as semver packages, with a documented deprecation path for every breaking change. A consumer that hasn't migrated by the deprecation deadline gets an automated warning in their build pipeline, not a silent regression on Monday morning.
Failure mode 5: the system has no relationship to design files
Tokens live in a JSON repo somewhere. Figma libraries live in a different team's Figma org. The tokens drift and nobody notices because there is no automated bridge between the two. By month nine, designers and engineers are working from different colour palettes and no one can agree which is canonical.
The fix is automation, not vigilance. Tools like Style Dictionary, Tokens Studio, or Specify-style platforms can sync tokens between Figma and code. The exact tool matters less than the existence of the bridge. Without it, the gap will open and you will not see it open.
Failure mode 6: the system is documented at the wrong level
Most design system documentation reads like a museum catalogue: "this is the button. The button has these properties. Here are screenshots of the button." That is description, not guidance. The documentation a consumer actually needs is decision-shaped: "use the primary button for the main action on a page; use the secondary button for the secondary action; if you are tempted to use both at the same priority, you have a layout problem, not a button problem".
Decision-shaped documentation makes the system survive personnel changes. Description-shaped documentation does not.
Failure mode 7: the system is measured by component count
A design system's success is not "we have a hundred components". It is "ninety percent of net new product UI uses our components, and the team writes less custom CSS this quarter than last". One metric measures effort; the other measures outcome. The metric you choose shapes what the team optimises for.
We now track three metrics: adoption (percentage of net new UI built from system primitives), drift (number of one-off CSS rules that override system tokens), and freshness (median time from a component being shipped in product code to being represented in the system). All three are leading indicators. Component count is a vanity metric.
What a healthy system looks like
A few signs you are doing this well:
- The DRI's calendar is full of consultations from product teams asking "should I use the system here, or is this an exception?"
- New product UI is shipping in days, not weeks, because primitives compose cleanly.
- Designers and engineers cite the same component names in conversations.
- The system has a release cadence (we like fortnightly) with public release notes.
- Junior team members onboard onto product code by reading the design system first.
These are not glamorous signals. They are the absence of friction, which is what every healthy system feels like. The dramatic moments — the relaunch, the rebrand, the migration — are downstream of the everyday discipline. Build the discipline first; the dramatic moments will go fine.