Glossary
What is a design system?
The shared source of truth for a product's interface, plus the rules for using it.
Updated 2026-09-09
A design system is the shared source of truth for how a product's interface looks and behaves: tokens, components, patterns, documentation, and the rules that govern them.
It stacks in layers. Tokens hold the raw decisions. Components turn those into buttons, inputs, and cards. Patterns combine components into solved problems like an empty state or a destructive confirm. Documentation says when to use which, and that last layer is the one teams skip.
The uncomfortable part is that a design system is a product and your own team is the user. Adoption is the metric, not component count. A healthy system means a squad can ship a feature without inventing a new button. An unhealthy one has 300 Figma components and every product surface still looks slightly different.
Drift is the constant enemy. Figma and code diverge unless tokens have one source and there is a real sync step. Once two teams depend on you, versioning becomes real work: breaking changes need a migration note and a deprecation path, or people fork your components and you lose the system quietly.
Where people get this wrong
- A component library is not a design system. Without docs and adoption it is a folder of code.
- Governance beats coverage. Fifteen components people actually use beat a hundred nobody trusts.
- If contributing is hard, teams will build their own. Make the contribution path shorter than the workaround.