Design system basics: where to start
What a design system contains
A design system is a shared set of decisions that designers and developers reuse, so that a product looks and behaves consistently. It is more than a Figma library or a code package.
Tokens
Named values for colour, type, spacing, radius and shadow.
Components
Reusable parts such as buttons, inputs and cards.
Patterns
Solutions that combine components, such as forms or empty states.
Documentation
Guidance on when and how to use each piece.
Not every team needs a large system. A small product can start with a shared style guide and a handful of components. What matters is that decisions are written down once and reused.
Start with an audit, then begin small
Before creating anything, collect screenshots of the existing interface and group similar elements. An audit usually reveals many near-duplicates: several greys, several button styles, several sizes of the same heading. These show where a system will help most.
- Define colour tokens, a type scale and a spacing scale.
- Build the most used components first: button and input.
- Use them in a real product screen before adding more.
Add a component only when it appears in at least two places, or when inconsistency is causing real problems. This keeps the system small and based on use.
Naming, guidance and ownership
- Naming. Name tokens by purpose, not by value: <code>color-text-primary</code> ages better than <code>dark-grey</code>. Use the same names in design and code.
- Usage guidance. For each component, write when to use it, when not to, and a short do and don’t pair. Include accessibility notes and states.
- Ownership. Name who maintains the system, and describe how others can propose a change: a request, a review, a decision.
- Versioning. Number releases and keep a changelog, so teams know what changed and whether an update could break their screens.
Documentation should live where people already work, and it should show real examples with code next to the design. A page that is out of date is worse than no page, so give each page an owner and review it when the component changes.
Plan for change from the start. Mark old components as deprecated for a period, say what replaces them, and remove them only after teams have had time to migrate.
Measure adoption, not component count
A large library that nobody uses has failed. Better signals are how many screens use system components, how many one-off overrides exist, and whether designers and developers find what they need quickly.
Grow the system from real needs, not from a wish to be complete.
This guide was drafted with AI assistance from public standards and references. For the exact wording of a standard, use the sources listed above.