Most teams end up here the same way. A new screen ships with a button that looks almost like the others. Then another screen does the same. A few months later nobody can say which button is the right one, and every fix has to be repeated on four other screens.
A design system is the usual answer, though people mean quite different things by the term.
What a design system is
It is a set of decisions the team has agreed to make once: how spacing works, what each colour means, what a button does when it is disabled. Those decisions are written down in a form that designers and engineers can both use, and somebody is responsible for keeping them current.
In practice it has three layers:
- Foundations: colour, type, spacing and motion, stored as design tokens.
- Components: buttons, inputs, tables, dialogs and the patterns built from them, designed and coded to match.
- Guidance: when to use each component, how it behaves, and what to do when it doesn't fit.
Design system, component library, style guide
People use these words interchangeably, but they describe different amounts of work.
| Term | What it is | Who uses it |
|---|---|---|
| Style guide | A document of visual rules | Designers and marketing |
| Component library | Reusable interface built in code | Engineers |
| Design system | Tokens, components and guidance, with owners | Everyone who ships the product |
A style guide and a component library both go stale unless someone is checking. A design system names that person.
What goes into one
Design tokens
Tokens are named values for the smallest decisions: a colour, a spacing step, a corner radius. The Design Tokens Community Group maintains an open format for them, and describes its work like this:
We steward the Design Tokens specification so teams can share visual language reliably across design tools, codebases, and platforms.
Design Tokens Community Group, designtokens.org
A small set looks like this:
{
"color": {
"ink": "#181817",
"ink-secondary": "#6e6d68",
"accent": "#a11a56"
},
"space": { "1": "4px", "2": "8px", "3": "16px", "4": "24px" },
"radius": { "card": "14px" }
}Name a token for the job it does, such as ink-secondary, rather than the value it holds, such as grey-600. When the grey changes, the first name is still true.
Components
Components are where most of the visible work happens, and where the scope tends to grow. A reasonable rule is to build a component once you have needed it a third time, and not before.
Documentation and ownership
For each component, write down when to use it, when not to, and who to ask. Then decide who approves changes. Without a named owner, nobody decides and people stop using it.
How to tell whether you need one
You are probably ready if more than one team ships interface into the same product, if engineers rebuild patterns because they can't find the original, and if design reviews keep reopening decisions that were already settled.
You can probably wait if one designer and a few engineers own the whole product and the interface is still changing every week. A system built too early just records guesses.
What it costs
The first months cost more than they return. You are auditing screens, naming things and rebuilding components that already worked. The payback shows up when a third team joins, or a rebrand lands, or the product needs a dark theme.
Building the first version
Work through these in order:
- Screenshot every distinct button, input and table in the product. The spread is usually the argument for doing this at all.
- Pick the ten patterns used most and leave the rest for now.
- Define tokens before components.
- Build each component in design and in code together, so they match.
- Name an owner and set a regular review. Weekly is enough.
Three mistakes to avoid:
- Trying to cover every case, which delays everything.
- Treating it as a project with an end date, so it goes stale.
- Building it without engineers, so the components don't match what ships.