Teams build component libraries and call them design systems. The library is the visible part — buttons, inputs, modals, tables — and it is the smaller half. A design system is the set of decisions that make those components consistent: the spacing scale, the type scale, the colour roles, the interaction patterns, and the rules about which component to use for which job. Without those, you have a folder of components that will diverge, because every new screen requires a fresh judgement.
Start with the tokens rather than the components. A defined spacing scale, a type scale, a palette expressed as roles — primary action, destructive action, muted text, surface, border — rather than as colour names. Tokens are what let you change something globally later, and they are what stop the twelfth developer inventing a fourteen-pixel gap because it looked right on their screen. They also make dark mode and theming possible instead of a rewrite.
Build components from real usage, not from a catalogue. A system designed by cataloguing every component a team might need produces forty components, of which eight are used and the rest are maintenance. Look at the screens you actually have, find the patterns that repeat, and build those. Add a component when the same thing has been built twice and is about to be built a third time — that rule alone produces a well-scoped system.
Documentation is what determines adoption, and it needs to answer when as much as how. A component page showing every prop is a reference; what a developer needs is guidance on which of the three similar components applies to their situation, what the accessible behaviour is, and what not to do. Systems that document usage decisions get used correctly; systems that only document APIs get used in whatever way the first person guessed.
Accessibility belongs inside the components rather than in a checklist beside them. Keyboard behaviour, focus management, ARIA semantics, contrast that meets the ratio — building these into the shared components once means every product using them inherits the correct behaviour without any individual developer needing to know the details. This is the single largest practical benefit of having a system at all, and it is usually discovered rather than planned.
Then decide who owns it, because a design system with no owner becomes a snapshot. It needs someone accountable for versioning, for reviewing additions, for deprecating what is unused, and for saying no — because the fastest way to destroy a system is to accept every team's special case into it. That ownership does not need a dedicated team at most companies; it needs one named person with a few hours a week and the authority to refuse.
