The term covers three things that tend to be sold as one. Tokens are design decisions expressed as machine-readable values, so a colour, a spacing step or a type size lives in a single place and every surface reads it from there. Components are those decisions implemented in the framework the product is built in, versioned and installed like any other dependency. Usage rules are the part teams skip and then need most, because a component with no written account of when it is the wrong choice gets used everywhere and stops meaning anything. Documentation describes a system; it is not one. The test is mechanical. If changing a value in one repository changes the live product, you have a system. If it changes a page in a wiki that somebody will contradict next quarter, you have a style guide, and the naming will not make the interface agree with itself.
The cost is maintenance, and it lands on a named person
Adoption is the only measure worth tracking, and it never happens on its own. Teams under deadline pressure copy a component, change two lines and ship the copy, and every fork is a future inconsistency plus a fix that will not propagate. Preventing that is somebody's actual job: reviewing contributions, cutting releases, writing migration notes when a component changes shape, and deciding when an old one is retired. Fund that work or expect drift within the first year. What repays the cost is rarely aesthetic. An accessibility defect corrected in a shared component is corrected everywhere at once, which is the only version of that task that ever finishes. Screens get assembled from parts whose behaviour is already settled, so review time shifts from how something looks to whether the thing is worth building at all. Ownership also closes a licensing conversation: components, icons and layouts you built yourself are cleared once, leaving type as the last bought item to track, still governed by its font licence whatever the token points at.
- A versioned package installed like any other dependency, with releases you can pin and upgrade on purpose rather than discovering in a diff.
- Tokens as the single source of values, so a brand change becomes a release instead of a search across repositories and a month of stragglers.
- Usage rules that state when not to use a component, which is the guidance that stops the wrong pattern spreading into places nobody reviewed.
- A visible intake route for teams needing something the system lacks, because the alternative to intake is a fork that nobody argues about until it ships.
- A deprecation policy with migration notes, since a library that can never retire anything only grows, and growth is what makes it unlearnable.
- A named maintainer with hours allocated. Everything above is a hobby without this one, and hobbies lose to deadlines every time.