Design systems earn their keep on the second project

On the first project, a design system slows you down. You're deciding things you could have improvised: what a card is, how many button variants exist, what the smallest allowed type size is. Every one of those decisions costs a conversation you didn't strictly need to have.

That's the honest trade, and it's why systems get shelved. The return arrives later — on the second surface, the second team, the second year — when the decisions are already made and the work becomes assembly rather than invention.

What a system is actually for

A design system is often described as a component library. That undersells it. The components are the artifact; the decisions are the product.

The value is that nobody re-litigates the palette, the focus state, the card radius, or the empty-state pattern. Those questions were answered once, deliberately, with accessibility and brand accounted for — and every screen built afterwards inherits that thinking for free.

The point of a system isn't consistency for its own sake. It's that good decisions become the default, and drift takes effort instead of happening on its own.

Keeping one small enough to survive

The systems that die are the ambitious ones — the ones that tried to cover every case before anyone needed it. A few habits keep a system alive:

• Start from what exists. Build from the screens you actually have, not the taxonomy you imagine.
• Add a variant on the second use, not the first. One-off needs stay one-offs until a pattern proves itself twice.
• Encode the decision, not just the pixels. A token named for its role survives a rebrand; one named for its color doesn't.
• Name things after their job. 'Primary action' outlives 'green button' — and stops the next person guessing.
• Let it be edited. A system nobody can change becomes a system everybody works around.

The part that isn't design

The hardest part of a design system isn't building it. It's the agreement that it's the default — that new work starts from it and departures are deliberate, not accidental. That's an organizational decision, not a design one, and no amount of documentation substitutes for it.

Which brings it back to the second project. That's when you find out whether you built a system or a folder of components: does the next thing get faster, or does everyone start again?