Failure mode 1: the design system team is isolated
The quickest way to kill a design system is to make it a separate team's problem. When the people building components are disconnected from the teams consuming them, you get a system that solves yesterday's problems. Effective design systems have embedded contributors from product teams, not just a central team publishing updates.
Failure mode 2: tokens are an afterthought
Design tokens are the foundation — not a nice-to-have. Teams that bolt tokens on after building components spend months retroactively naming things and arguing about whether 'brand-blue-500' or 'interactive-primary' is the right token name. Neither is wrong, but the inconsistency compounds. Start with your token layer.
Failure mode 3: documentation is aspirational
Most design system documentation describes how things should work, not how they do. Docs written at launch rarely survive the next sprint. The teams with living documentation have made it part of the component-publishing process — PRs don't merge without doc updates, and the docs are generated from the code, not written separately.
What holds
The design systems that survive at scale have three things: clear ownership (someone whose job is the system), contribution patterns (how teams outside the core team submit and adopt components), and a usage feedback loop (how the core team learns which components are causing friction). Everything else — the tooling, the token naming, the component API shape — can evolve. These three things have to be in place from the start.