This case study intentionally excludes employer-specific details, confidential operating information, and unverified performance claims. It focuses on a product model that can be discussed through public evidence.
Context
In a large organization, a shared design system sits between a central team and many downstream product teams. Those teams work across different products, constraints, and stages of growth. A common system can help the organization retain what it has learned, but only if teams can use it to make progress.
Problem
Adoption is often framed as compliance: a team either uses the approved system or departs from it. That binary view misses important evidence. A team may detach a component because it has a legitimate local need, because it is experimenting, or because the shared system asks it to make too many compromises. Non-usage and thoughtful adaptation are not the same signal.
Constraints
- Downstream teams remain responsible for their own product outcomes.
- Shared coherence matters, but local needs do not disappear.
- Organizational strategy changes the amount of experimentation a system should expect.
- Mandates can increase nominal usage while making adoption data less meaningful.
- No universal detachment target can be supported by the available evidence.
My role
The public record supports the product framing represented here: treating downstream teams as customers with choices, defining detachment as a signal to investigate, and articulating a context-sensitive model for system adoption. Employer-specific scope, responsibilities, and team context are intentionally omitted until they can be verified for public use. The published version of the model appears in The Design System Detachment Curve.
Approach
The model separates usage, detachment, and non-usage. It looks for patterns across teams and components rather than judging a single override in isolation. It then connects those patterns to organizational context: expansion and experimentation may produce different healthy behavior than consolidation and standardization.
Important decisions
- Treat divergence as evidence before treating it as failure.
- Evaluate patterns at the system level while investigating the local reason behind them.
- Avoid presenting an invented “ideal” detachment percentage.
- Make the shared system the easiest credible path to a team's desired outcomes.
- Use adoption behavior to improve the system's learning loop, not merely its compliance reporting.
Outcomes
The public outcome is a reusable decision model for discussing design-system adoption without false precision. No confidential business result, adoption metric, or employer-specific outcome is claimed here.
Evidence
- The published essay The Design System Detachment Curve
- The accompanying detachment-curve diagram
- A documented definition of detachment and a set of limits on how the model should be interpreted
Lessons
A design system is not only a component library. It is a relationship between a shared organizational capability and the teams expected to rely on it. Adoption improves when the central system learns from the edges and absorbs more of the complexity that individual product teams would otherwise have to manage themselves.