The short version
A design system is two things. Parts, and rules.
The parts are buttons, forms, cards, spacing, colour and type. Real ones that work, that a developer can use today.
The rules say when to use which part. That is it. Everything else people bolt onto the definition is optional.
What it is not
- A style guide. That describes how things should look. A system hands you the thing itself.
- A folder of design files. If only designers can open it, half your team is locked out.
- A brand book. Related, but a brand book covers voice and story. A system covers parts.
The difference matters because all three get sold under the same name, and they are not the same purchase.
How to tell if you have one
There is one test. Ask a developer to build a new page from existing parts, and watch.
If they assemble it from things that already exist, you have a system.
If they copy code from another page and edit it, you have a habit. Habits are fine. They also drift, quietly, until nothing matches.
Why they fail
We have seen more failed design systems than successful ones. The failures look alike.
- Built up front, before anyone needed it, so it guessed wrong.
- Too big. Ninety components, forty of them used exactly once.
- Owned by nobody once the people who built it moved on.
- Slower to use than copying and pasting.
That last one kills more systems than everything else combined.
The rule we use
A component enters the library after it has appeared three times in real work. Not before.
It sounds slow. What it means is that every part has proven demand behind it, and nobody has to be talked into adopting something they already asked for.
How big should it be?
Smaller than you think. Sixty parts is plenty for most products.
If your library has grown past a hundred, some of those are variations that should have been options on a part you already had.
A small system gets used. A big one gets searched once, then abandoned.
Worth remembering
In four lines
- A design system is parts plus rules. Nothing more complicated.
- If a developer cannot use it, it is a style guide.
- Add a component after it has appeared three times, not before.
- Sixty parts is plenty. A hundred usually means duplication.
Questions we get asked
Do small companies need one?
Only if the same things get rebuilt repeatedly. With one designer and one developer, a shared file and a short conversation often does the job better.
Who should own it?
One named person, with time set aside for it. Systems owned by a committee stop being maintained within about a year.
How much does one cost?
It depends whether it comes out of real product work or gets built separately. Built alongside a redesign it is far cheaper, and far more likely to survive.
Read next
Working on this yourself?
We help teams sort this out for a living. Tell us what you’re building, or see how it went for other people.