When a Design System Is Actually Worth Building

The first question in every design system conversation is when to build one.

The answer is not about company size. It is about whether you are making the same decision more than once.

Too early

One product, twenty screens, one designer. Build a design system in that situation and it will not get used.

The reason is simple: at that scale, making the thing directly is faster than defining a component, documenting it, and assembling from it. People pick the faster path, correctly.

There is a second problem. The product is not settled yet. If the direction shifts in six months, every component you defined gets rebuilt. A design system built early goes stale early.

Too late

Start from several hundred screens, multiple teams, and years of inconsistent decisions, and the migration does not finish.

You can define new components, but replacing the existing screens is enormous work, and that work produces no direct business value, so it never rises up the priority list. The result is old and new components coexisting for years.

That can be worse than having no system at all, because now there are two correct answers to every question.

Three conditions

If two or more of these are true, it is worth building.

You are making the same decision repeatedly. How buttons look, how spacing works, how errors appear. If the same discussion keeps happening on different screens, it is time to decide once and write it down.

Three or more people are building. Designers and engineers together. Two people stay aligned by talking. Past three, they stop.

There is more than one product, or there will be. Consistency across products requires a shared definition.

If one or two people are building a single product whose direction is still moving, it is too early.

The smallest useful first version

Do not define everything. There is an order.

Colour, type, spacing first. These three change rarely and affect every screen. Defining only these lifts visual consistency substantially, and the work is small.

Then the five components you use most. Button, text input, select, notification, and the row in a list. In most products those five make up the majority of what is on screen.

Then the states. Loading, empty, error, no permission. Standardising these prevents every screen from inventing its own answer later.

Everything after that can wait until it is needed. Components defined before anyone asked for them are usually components nobody uses.

What kills them in year two

No owner. The person who built it moves to another team, updates stop, the documentation drifts from the code, and once it has drifted nobody trusts it again.

No way to add anything. If getting a new component approved takes six weeks, teams with deadlines will not use the system. You cannot win that argument with governance. The compliant path has to be the fast path.

Counting components as the result. How many components exist is a meaningless number. What matters is what share of the shipped interface is actually built from the system. That number is almost always much lower than the team believes.

If you are commissioning one

Do not let the deliverable be "a set of components".

You need the components plus the method for running them. Who adds a new one and how, in what order existing screens get replaced, and what principle applies when a case is ambiguous. A handover without that is unused within a year.

A design system is not a project, it is an internal product. Its users are your colleagues, who have deadlines and the option of ignoring it. Treat it that way and it survives year two.