What a design system is, and when you need one
Every product team makes the same small decisions again and again: which blue, how much space, what a button looks like when disabled, how an error is shown. Without a shared answer, each designer and developer decides afresh, and the product slowly fills with near-duplicates. A design system records the decisions once, turns them into parts that can be reused, and keeps the design and the code in step.
| Layer | What it contains | Example |
|---|---|---|
| Foundations | Named values for colour, typography, spacing, radius, shadow, motion | A spacing scale, a set of text styles |
| Components | Reusable interface parts, with their states and variants | Button, input, table, dialog, navigation |
| Patterns | Proven solutions for recurring tasks | A form with validation, an empty state, a search with filters |
| Guidelines | When and how to use each part, with writing and accessibility rules | When to use a dialog and when a page |
| Code library | The components implemented and packaged for developers | A package installed in each product |
A small team with one product can go far with a tidy set of design files. A full system pays when several people or teams build interfaces in parallel, when there is more than one product or platform, or when inconsistency has become visible to customers. Our comparison of a design system and a UI kit helps decide how much you need.
Start with an audit of what exists
The worst way to begin is to design an ideal system in isolation and then ask teams to adopt it. Begin instead by collecting what your products already contain. Take screenshots of every button, input, table, card, dialog and heading across your products and group them. The result is usually sobering: a dozen button styles, several greys that differ by a hair, three ways of showing an error.
- 01
Collect
Every distinct instance of each interface element, from the live products and the code.
- 02
Group and count
How many variations exist, and which are used most.
- 03
Decide what is intentional
Some differences are deliberate. Most are accidents. Mark each.
- 04
Choose the survivors
For each element, the version to standardize on, improved where needed.
- 05
Note what is missing
States nobody designed: loading, empty, error, disabled, focus.
The audit gives the system its content, shows stakeholders why it is needed and provides a baseline against which progress can later be measured.
Agree the foundations
- Design tokens. Name every value, so that a colour is referred to as primary action or border subtle and never by its code. Tokens let a change be made once and flow everywhere, and they are how design and code share the same values.
- Colour. A limited palette with defined roles, checked for contrast against accessibility guidelines in every combination that will be used.
- Typography. A small scale of text styles with sizes, weights and line heights, tested with your longest content and in every language you support.
- Spacing and layout. One scale for gaps and padding, and rules for grids and breakpoints.
- Themes. If you need dark mode or several brands, structure tokens for it from the start. Adding it later is laborious.
- Direction. If any product will support a right-to-left language, build components with direction-neutral spacing now.
- Accessibility. Focus indicators, target sizes, keyboard behaviour and screen reader labels decided at this level, so that every component inherits them.
Build components in design and in code together
A component that exists only in a design file is a picture. One that exists only in code is invisible to designers. The system works when each component exists in both, with the same name, the same variants and the same behaviour, and when a designer and a developer build it as a pair.
- 01
What is it for, and what is it not for?
What to define for each componentA sentence on purpose prevents the same need being met by three components.
- 02
Which variants and sizes?
What to define for each componentAs few as the audit showed are needed. Every variant is something to maintain.
- 03
Which states?
What to define for each componentDefault, hover, focus, active, disabled, loading, error. Missing states are where products look unfinished.
- 04
How does it behave?
What to define for each componentKeyboard interaction, what happens with long text, how it adapts to narrow screens.
- 05
What content rules apply?
What to define for each componentLabel length, capitalization, tone of messages.
- 06
Is it accessible?
What to define for each componentTested with keyboard and a screen reader before release.
Start with the ten or so components that appear on nearly every screen, taken from the audit. Shipping those well, and getting them used, is worth more than a complete catalogue nobody has adopted.
Document for the people who will use it
Documentation is the interface of the system. Designers and developers will judge the whole effort by whether they can find a component, see how it behaves and copy it into their work in a minute. Each component page should show live examples, the available options, guidance on when to use it and when not to, and the code to include it.
Keep documentation next to the code and generate as much of it as possible from the components themselves, so that it cannot fall out of date. A separate document maintained by hand describes the system as it used to be.
A worked example
A design system for a logistics software company
This example is invented to show a system built from an audit and adopted gradually. A logistics software company has a web application, a customer portal and a driver app, built by three teams.
- AuditScreenshots reveal 14 button styles, 9 greys used for text and 5 date pickers. Only the primary button looks the same in all three products.
- FoundationsA token set is agreed: 6 colour roles with tints, 7 text styles, one spacing scale. Two contrast failures in the existing palette are corrected.
- First releaseTwelve components, chosen by frequency in the audit, are built in the design tool and as a code package by one designer and one developer over a quarter, with the three teams reviewing.
- AdoptionThe customer portal, due for new features, adopts the package first. The team reports gaps weekly, and four components are extended in response.
- GovernanceA part-time owner, a shared channel for requests and a release every two weeks with notes. A team may propose a new component by showing it is needed in two places.
A year on, two of the three products use the package for most screens. The count of button styles in production has fallen from 14 to 3, and new screens in the portal are assembled noticeably faster than before.
Govern and maintain it
A system that lasts
- A named owner with time allocated
- A clear route for requests and contributions
- Versioned releases with notes on what changed
- A stated policy for retiring old components
- Adoption measured, and gaps acted on
A system that decays
- Built as a project, then left with no owner
- Teams copy components and modify their copies
- Design files and code drift apart
- Breaking changes released without warning
- New components added on request with no test of need
- 01
Decide the ownership model
A small central team, or contributors from product teams coordinated by an owner. Both work. No owner does not.
- 02
Set contribution rules
How a team proposes a change, who reviews it and what quality bar it must meet.
- 03
Version and announce
Releases numbered so that products can upgrade when ready, with notes and migration guidance for breaking changes.
- 04
Measure adoption
Share of screens or code using system components, and the count of one-off overrides. Review it regularly.
- 05
Prune
Remove or merge components that are barely used. A system grows heavier unless someone takes things out.
Design system checklist
Design system checklist
0 of 11 checkedWhat to do next
Spend an afternoon collecting every button and every text colour from your live products onto one page. Show it to the people who fund design and development. That single page usually makes the case better than any presentation, and it is the first step of the audit.
Our design systems development page explains how we build systems alongside product teams. Show us your products and we will say how much of a system you need.
Common questions
How long does it take to build a design system?
A first useful release, with foundations and the most used components in design and code, is a matter of focused work over a limited period by a small team. A system is never finished, though. It grows and changes with the products it serves. Plan the first release as a project and everything after it as ongoing maintenance with its own budget.
Should we adopt an existing open-source system or build our own?
Building on an established open-source component library saves a great deal of work on behaviour and accessibility, and many organizations style one to match their brand. A fully custom system makes sense when your products have unusual interaction needs or when design distinctiveness is central. Either way, your tokens, patterns and guidelines remain your own.
Who should own the design system?
A named person or small team with time set aside, usually a designer and a developer working together, answerable to whoever leads product. Ownership as a side task alongside full product work tends to fail. In smaller companies a part-time owner with clear authority, supported by contributors from each team, is a workable arrangement.
How do we get teams to use it?
Make it the easiest way to build. Components must be reliable, documented and quick to install, and requests must be answered promptly. Start with one team that has a real need, solve their problems visibly and let results persuade the others. Mandates without quality produce quiet workarounds, and private copies of components.
How do we know the design system is working?
Track the share of interface built from system components, the number of one-off overrides, the time taken to assemble new screens and the count of visual inconsistencies found in review. Feedback from designers and developers matters too. A rising share of adoption with falling overrides is the clearest signal that the system is serving its users.