A design system exists, is well built, and teams keep building their own components anyway. What is the diagnosis?

The usual causes

• The component does not do what the team needs, and the system offers no way to extend it. A component with no escape hatch forces a rebuild the moment requirements diverge slightly.
• Contribution is harder than building locally. If adding a variant means a review board, a design approval and a two-week release cycle, the rational choice is a local component.
• Discovery fails. Teams do not know the component exists, which is a documentation and search problem rather than a compliance one.
• Release cadence is too slow. A team blocked for a month on a needed change will not wait.
• The system is stylistically prescriptive in places it should be flexible, and flexible where it should be prescriptive.

What makes adoption happen

• Escape hatches by design — style overrides, composition, or a lower-level primitive to build on — so divergence does not require abandonment.
• A fast, low-friction contribution path with a short release cycle, so extending the system is easier than forking it.
• Usage measured, so the team knows what is adopted and what is being reimplemented. This is the input to everything else and is usually absent.
• The system solving hard things teams do not want to solve: accessibility, keyboard interaction, focus management, internationalisation, theming. These are what make adoption self-interested rather than compliance-driven.

The framing

Adoption is a product problem, not a governance problem. Mandates produce technically-compliant implementations and resentment. A design system that is the easiest path gets adopted without a mandate, and a design system that is not will not be saved by one.