A team had a complete component library and three production products. The new dashboard copied an old button instead of importing the official one. The library version needed a provider, carried assumptions from a marketing site and made the simple screen harder to ship. The team was not undisciplined. The system had become more expensive than duplication.
A design system earns its cost through repeated decisions across enough people and product surfaces. Taste is not the threshold. Coordination cost is.
Count teams and surfaces before components
One product team working in one application can often move faster with local components and a small set of tokens. The shared system becomes valuable when independent teams solve the same interaction, when several surfaces must express one brand, or when accessibility and behaviour drift faster than reviewers can catch.
Count consumers, release cycles and recurring decisions. A website, account area, internal tool and native app are not merely more screens. They have different rendering, input and release constraints. Shared foundations may help, but forcing one component implementation across all of them can create a false standard.
Start where coordination repeats. Do not begin with an inventory of everything that could become a component.
Adoption fails when the system charges a tax
Teams abandon systems that are slower to understand than local code. Common causes are vague component boundaries, prop combinations that encode historical accidents, weak documentation, inaccessible defaults and release processes that require a separate negotiation. If every exception needs permission from a central team, people fork components quietly.
Visual completeness can hide functional gaps. A button exists, but loading, error, focus and analytics behaviour do not. A form field looks correct, but cannot express the product's validation. The system then standardises appearance while every team rebuilds behaviour.
Measure the time from need to production. Adoption is a service outcome, not a download count.
Governance is product work
A design system needs ownership, prioritisation, support and deprecation. Someone must review contributions, answer usage questions, publish changes and migrate consumers. Without that capacity, the library freezes while products continue moving.
Contribution cannot mean send us a pull request. Product teams need a clear path from local pattern to shared primitive, including evidence that the pattern repeats. The system team needs authority to say no when a request is product-specific.
Versioning should communicate behavioural change, not only visual change. A focus fix, DOM change or new default can break consumers even when screenshots look identical.
Build foundations before a catalogue
The most durable layer is usually smaller than the showroom suggests: colour roles, typography, spacing, motion, focus treatment, form semantics and layout primitives. These create consistency without forcing every screen into a universal component.
Add shared components where repeated use is proven and behavioural consistency matters. Keep escape hatches explicit. A product-specific composition can use shared foundations without pretending it belongs in the core library. Delete unused experiments. A design system is not an archive of every interface the company has made.
Test whether the system is worth it this week
List active teams and product surfaces. Find repeated components that have already diverged and record the cost of those differences: defects, accessibility gaps, duplicated work or inconsistent customer behaviour. Choose the pattern with the clearest recurring cost.
Build or repair that slice with a real product team. Document usage, edge cases and migration. Measure how long adoption takes and how many local overrides remain. If the shared version cannot beat a local solution on delivery and maintenance, fix the system before expanding it.
The uncomfortable answer may be that a full design system is not yet justified. A disciplined component folder can be enough. The right system begins when repeated coordination costs more than shared ownership, and it survives only while the shared path remains the easiest credible path.