Your Design System Failed Before Anyone Used It
Your design system team delivered fifty components over nine months. The product squads use fifteen of them. The other thirty-five are documented, accessible, and invisible.
Three product teams have quietly built their own button components. Nobody talks about it.
This is not a culture problem. It is not a communication problem. It is an abstraction problem, and the design system team built it in.
The Gap Between What Design Systems Promise and What Teams Need
The pitch for design systems is persuasive: one source of truth, consistent user experience, faster development, accessible by default. The business case writes itself. Companies invest in them, write the documentation, build the Storybook, run the kickoff.
Then adoption stalls at 30%.
A LogRocket analysis of design system failure patterns tracked a consistent dynamic across mature systems: the longer a design system exists, the more complex it becomes, and the less likely individual teams are to use it as intended. The average component in a mature design system carries 12–18 props. The same component when first extracted from production code had 3–4. Those additional props represent hypothetical use cases — edge cases that seemed worth handling in a design review but never appeared in actual product work.
Components with 18 props are harder to use than components with 4. They require reading documentation before use, not as an occasional supplement. Teams under deadline skip the documentation and write something local. The design system team diagnoses this as low discipline. It is actually a rational response to a poor cost-benefit ratio.
The Abstraction Level Problem
There is a specific mistake underlying most design system failures. It is more structural than cultural, and it's the reason pointing at "adoption challenges" misses the real issue.
Design systems built top-down pick the wrong abstraction level.
The team asks: What is the most reusable, flexible representation of a button? They build that. A button component that handles loading states, icon placement, destructive variants, full-width layouts, and disabled states — all configurable via props, all correct. Flexible. Comprehensive. Future-proof.
What the product teams actually need is the specific button used in the checkout flow. The specific button used in the confirmation modal. The specific button used in the data table action bar. These components share almost nothing except visual treatment.
The flexible generic button serves none of these use cases well. It serves them adequately with significant configuration. Teams that ship fast don't want adequate-with-configuration. They want correct-with-no-configuration. If configuring the design system component correctly takes longer than writing a local one, teams write local ones. Every time.
This isn't a failure of the system's design principles. It's a failure of the system's level of abstraction. Generic components solve the design team's problem: maintaining visual consistency across a large surface area. Specific components solve the product team's problem: shipping features that behave correctly without homework. These are different problems, and a top-down system solves one of them.
What Actually Works: Extraction, Not Specification
Design systems with real adoption share a pattern. They were discovered, not planned.
The process: product teams build features. They write local components that do exactly what the feature needs, no more. Over time, the same button appears in six places. Someone notices it's identical across all of them. They extract it into a shared library, replace the local versions, and document the one true version.
That extracted component arrives in the system with real-world constraints baked in. It has exactly the props that actual use cases required. It handles the edge cases that feature teams actually hit — not the hypothetical ones that looked important in a design review. It's tested in production, not in Storybook.
A 2023 DEV Community case study documented a design system rescue at a mid-sized product company. The existing library had 120 components and 30% adoption. After switching to an extraction model — identifying the 20 components that appeared consistently across production code, deprecating or archiving the rest, and establishing a structured intake process for promoting new patterns — adoption reached 78% within six months.
The team invested less in the system, not more. The difference was a different definition of what the system was for: capturing what the product actually does repeatedly, not specifying what the product might need someday.
The Governance Trap
Design system teams often mistake governance complexity for maturity.
Mature governance means a clear decision process: what patterns qualify for promotion into the system, who can propose changes, how long review takes, what happens when teams need something the system doesn't provide yet. Immature governance means a committee approval required to modify a border-radius token and a six-week queue for a component that a product team needs this sprint.
When the cost of working with the design system exceeds the cost of working around it, teams work around it. This is a governance failure, not a discipline failure. The system's advocates tend to diagnose it as "teams don't understand the value of consistency" — which may also be true, but doesn't change the incentive structure the governance model created.
Knowing when to deviate from a design system requires a governance model that formally allows for deviation. If every deviation requires sign-off, teams won't deviate formally. They'll deviate quietly — which is worse, because the drift is invisible and the system never learns what it's missing.
The design system should have an intake path that's faster and lower-friction than building locally. If it doesn't, teams will always choose local.
What the Teams That Ignored Your System Are Telling You
The product teams who built their own buttons aren't undisciplined. They're filing a bug report you haven't read.
They needed something the system didn't provide. Or they needed it in a timeframe the system couldn't match. Or the system's component didn't behave correctly for their specific context. Any of these is valuable information about what the system needs to fix.
This is the frame shift that separates surviving design systems from abandoned ones. Local component creation is a data point: the system had a gap, a team filled it themselves. The job of the design system team is to find out what the gap was, evaluate whether other teams have the same need, and decide whether to promote the local solution or build a better one. That feedback loop is the maintenance mechanism.
Most design system teams treat local deviations as compliance failures. They push harder on adoption, create more documentation, run workshops. The deviations keep happening because the underlying problem — the gap in the system's coverage of real use cases — hasn't been addressed.
The question isn't "why aren't teams using our system?" That question puts the problem in the teams. The question is "what were teams solving when they stopped?" That question puts the answer in your roadmap.