A design system is adopted and product teams still build their own components. What is the diagnosis?

The diagnosis

Bypass is a product signal, not a compliance failure. Teams build their own when the system's component is missing a needed variant, is harder to use than writing one, or cannot be adapted for their case.

Responding with a mandate leaves the gap in place and produces a system that is used under duress and diverges further from need.

The usual specific causes

• No escape hatch. A component that cannot be extended for one requirement forces a team to replace it entirely — one missing capability producing total defection.
• Slow to change. A team needing a variant waits for the design system team, so writing their own is faster.
• Built for the flagship product, so newer or different surfaces fit poorly.
• Accessibility and internationalisation handled inconsistently, so a team that cares about them cannot rely on the system and builds their own.

What makes adoption voluntary

• The component is genuinely faster to use than writing one, which includes documentation, examples and a predictable API.
• Extension is supported — a documented way to vary appearance or behaviour without forking.
• Contributions are accepted, with a named owner who has review capacity. Without capacity, contributions accumulate unreviewed and contributors stop after the second attempt.
• Accessibility built in, so using the system is the easiest way to be accessible — which is the strongest possible adoption argument and is frequently the design system's largest actual value.
• Versioned with a migration path, since breaking changes without one destroy the trust that voluntary adoption depends on.

The measurement

Voluntary adoption per component, not aggregate coverage. The aggregate hides that everyone uses the button and nobody uses the data table — and the components with low adoption are the roadmap, since teams have already done the analysis of why they did not fit.

The organisational point

A design system funded as a cost centre optimises for consistency; funded as a product it optimises for adoption — and only the second builds the documentation, examples and support that make consistency actually happen.