Most design systems fail. That's not a hot take; it's an industry-wide open secret. Companies invest six-figure sums in Figma libraries, component packages and documentation sites and then, twelve months later, discover that the product team has quietly built a parallel set of components in the app because using the official ones was harder than not. The system exists. Nobody uses it. The internal audit blames adoption. Adoption is a symptom, not the disease.
The disease, almost every time, is activation cost. If using your Button component takes fourteen props and a wiki to configure, engineers will use a styled <button>. If your color tokens are shipped as SASS variables that don't autocomplete in their IDE, they will hardcode hex values. If your documentation site takes eight seconds to load, they will read the source instead. Every one of those substitutions is a rational decision made in the moment. And every one is invisible in aggregate — until you audit the codebase and discover the system is now six competing systems, one of which is nominally official and the other five of which are what the team actually ships.
Three rules we hold ourselves to. First: ship the system as a dependency the same week the first product feature uses it. Not first — the same week. Nothing kills a system faster than the belief that the components are precious and need one more polish pass before they touch production. The system earns its keep by shipping under real product weight; anything you learn about it before then is theoretical. Second: require code review on token changes the way you require it on payments code. Tokens are the atoms; a stray change to a token propagates through the entire surface area of the product. Treat them like the load-bearing decisions they are. Third: make the documentation site faster to load than the engineer's IDE. Every second the docs take to open is a second an engineer spends deciding to skip them.
Treat consumers like product users — because that is what they are. They have alternatives. The alternative to your <Button /> is a styled <button>. The alternative to your <Card /> is a <div className="card">. If your components take fourteen props and a wiki to use, the styled <button> wins. Every single time. This is not a moral failure of the engineering team. It is a signal that the design system has failed to compete with the alternatives available in the same IDE window. A component library that competes on ergonomics wins consistently. A component library that competes on 'you should use this because it's official' loses just as consistently.
The most counter-intuitive rule: constraint, not coverage. The best design systems we've shipped are smaller than people expect. Twenty-eight components, five typography scales, twelve color tokens. The temptation, especially in a large organisation, is to build one component for every use case a team has ever encountered. That is how you end up with three near-identical Card components — one for marketing, one for product, one for admin — and a rule nobody remembers about which one to use where. Ship fewer components. Say no to a lot of use cases. The exceptional use cases can be composed from primitives. The system's job is to eliminate the ninety per cent of decisions that would otherwise be re-litigated a hundred times a week; it is not to solve every design problem your product will ever have.
One final rule, learned the hard way. The design system is a product. It has a roadmap, a changelog, a support channel, a metric for adoption, and, if you're doing it right, at least one dedicated maintainer whose job is not to build features in the primary product but to keep the system alive. Every design system we have seen fail failed because it was somebody's side project. The systems that succeeded had an owner whose calendar was defended for it. That is the single biggest predictor of whether the investment compounds or evaporates.