A Design System as a Contract Between Design and Engineering
Why a component library becomes a system only when the team agrees on rules, boundaries, and ownership.

A library of buttons and inputs is not yet a design system. The system emerges when designers and engineers share the same understanding of tokens, component states, and composition rules.
Start with language
A token name should describe its role rather than an accidental value:
color-action-primaryexplains intent;blue-600explains only the current color;space-sectionpreserves page rhythm;24pxdoes not explain where the value belongs.
A contract must be testable
A useful component defines its supported variants, states, and responsive behavior. If the team routinely bypasses its API with local styles, the contract is either too narrow or insufficiently clear.
A design system reduces repeated decisions. Its value is not the number of components, but the predictability of the result.