When a design system is worth building — and when it isn't

Design systems have become a default recommendation, which means plenty of teams build one before they need it. A system is a fixed cost paid upfront against a variable saving collected later. If you never reach the volume, you simply paid the cost.

The four signals

You have reached the break-even point when most of these are true:

• More than one designer and more than two engineers touch the interface regularly.

• You have shipped the same component three times with slightly different behaviour each time.

• Design review is spent on spacing and colour rather than on whether the flow works.

• A brand or accessibility change would require hunting through more than twenty files.

One or two of these is not enough. A solo designer working with two engineers on a single product will move faster with a shared Figma file and a folder of components than with a versioned, documented, independently released system.

Build it out of what you already shipped

The failure mode we see most often is designing the system in the abstract — a full component library, drawn in isolation, before anything uses it. It always over-covers the cases you imagined and under-covers the ones that actually appear.

The alternative: build the system out of your existing product. Take an inventory of every button, input and card currently in production. Group them. You will typically find eleven button variants that want to be three. Consolidate those three, replace the eleven, and you have started. Repeat for the next component only when you need it a third time.

A design system should be the compressed record of decisions you already made, not a prediction of decisions you might make.

Start with tokens, not components

Tokens — the named values for colour, spacing, type scale, radius and shadow — deliver most of the benefit for a fraction of the effort. They are also the part that survives a framework migration. Get them right and shared between design and code first; components can come later and be rebuilt when needed.

Keep the token set small enough to memorise. A spacing scale with six steps gets used correctly. One with twenty steps gets used arbitrarily, which is the same as having none.

Document the decisions, not the API

Prop tables generate themselves. What actually prevents misuse is a sentence explaining when to reach for a component and what to use instead — that a destructive button is for irreversible actions only, that the inline alert is for validation and the toast is for background results. Two sentences per component beats a page of generated documentation.

Budget for maintenance

A system nobody maintains becomes a system nobody trusts, and a system nobody trusts gets worked around. Assume ongoing effort of roughly a day a week from one person once it is live. If you cannot commit that, build less and keep it in the product codebase where normal code review keeps it honest.