Most design systems fail the same way. Someone builds a beautiful component library over three months, presents it, and within a year half the product is using one-off components again because the library did not have what people needed on the day they needed it.
The failure is almost never the components. It is that the system was treated as a deliverable instead of a service that has to keep being useful.
What a design system actually is
Four layers, and they are not equally important:
| Layer | What it holds | How often it changes |
|---|---|---|
| Tokens | Colour, spacing, type scale, radii | Rarely |
| Primitives | Button, input, text, icon | Rarely |
| Patterns | Form layout, empty state, data table | Regularly |
| Guidance | When to use which, and why | Constantly |
Tokens are where the value concentrates. Change one spacing value and 200 screens update. That is the whole promise, and it is achievable in a week.
Start smaller than feels serious
A first version that is genuinely enough:
- One type scale — five or six sizes, no more. Every size you add is a decision someone has to make later.
- One spacing scale — 4, 8, 12, 16, 24, 32, 48. Nothing between.
- Colour by role, not by name. “surface”, “text-primary”, “border” — not “grey-200”. Roles survive a rebrand; names do not.
- Five components — button, input, card, modal, nav.
- One page of guidance explaining when to use each.
That takes about a week and delivers most of the benefit. The three-month version delivers slightly more benefit and dramatically more maintenance.
Why systems get abandoned
| Failure | What it looks like | Fix |
|---|---|---|
| No owner | Requests go nowhere | One named person, even part-time |
| Too rigid | Designers copy and detach components | Allow variants; watch what people detach |
| Design and code drift | The library no longer matches the product | Same tokens feeding both |
| No contribution path | People build one-offs instead of asking | A documented way to propose a component |
| Documented nowhere | Only the author knows the rules | Guidance beside the component, not in a wiki |
The most useful diagnostic is the detach rate. When designers repeatedly detach the same component, the component is wrong — that is data, not indiscipline.
The token bridge is the part that matters
A design system that lives only in a design tool decays within months, because the product is built in code and the two drift apart quietly.
The fix is one source of truth for tokens, exported to both. Whether that is a JSON file, a plugin or a build step matters much less than the fact that changing a value in one place changes it everywhere. Without that, you have two systems that disagree — which is worse than none, because now nobody knows which is correct.
When you do not need one
- One person builds all the interfaces
- The product is a single, small surface
- You are still changing direction every few weeks
In all three cases a documented set of tokens is the right amount of system. Building the full thing before the product has settled means maintaining components for screens that will not exist next quarter.
Common questions
Should we adopt an off-the-shelf system?
For internal tools, yes — it is a large amount of free, accessible work. For a customer-facing product where the interface is part of the brand, you will end up overriding enough that you have built your own anyway.
How do we measure whether it is working?
Component adoption across screens, detach rate, and time from design to shipped. If adoption is high and detaching is low, it is working. If both are high, it is being tolerated rather than used.
Who should own it?
Ideally a designer and an engineer together, part-time. Design-only ownership drifts from the code; engineering-only ownership drifts from the intent.
Does a design system make accessibility easier?
Enormously — it is one of the strongest arguments for having one. Fix focus styles and contrast once in the primitives and every screen inherits it. The eight fixes mostly live at the token and primitive layer.
Leave a Reply