A design system is one of the few deliverables that can be simultaneously excellent work and a bad decision. It is expensive to produce, expensive to maintain, and it pays back only against a volume of interface work that many organisations do not have.

This is about identifying the point where it starts paying, and what to do before you reach it.

What it actually is

A style guide is a document. A component library is code. A design system is both, plus the rules for using them, plus somebody whose job includes keeping them true.

That last part is what people underestimate. A component library with no owner diverges from the product within two releases, and a divergent system is worse than none: designers stop trusting it, developers copy components to modify them, and you now maintain two versions of everything while paying for the illusion of one.

The signals that you need one

These are volume and coordination signals, not quality signals. A single site built by two people can look immaculate with no system at all.

  • More than one product or surface. A marketing site plus an application plus an admin tool. One product does not need a system; three sharing an identity do.
  • More than one team touching the interface, especially across time zones or across an agency boundary. The system is mostly a coordination mechanism.
  • The same component keeps being rebuilt. If four buttons exist because four people needed a button, that is the cost arriving.
  • Interface work is continuous rather than a project. A system amortises over releases. One release does not amortise anything.
  • Accessibility keeps regressing. A shared, correct component fixes a class of defect permanently. This is one of the strongest arguments for a system, and the least often made.

If fewer than three of those are true, the honest answer is that you need conventions rather than a system.

What to build instead, when you are below the line

The alternative to a design system is not chaos. It is a small set of decisions written down once.

Tokens - colour, type scale, spacing steps, radii - defined in one file and used everywhere. That alone prevents most visual drift and costs an afternoon. Then a handful of components that genuinely repeat: buttons, form fields, cards. Then a page that shows them together, so a new person can see what exists.

This is perhaps five per cent of the effort of a design system and delivers most of the consistency benefit for a single product. It is also the natural first stage of a real system, so nothing is wasted if you grow into one.

How design systems fail

The failures are consistent enough to list.

  1. Built ahead of the products. A system designed in the abstract encodes guesses. Systems that work are extracted from two or three real products, not designed before them.
  2. Documented but not coded, so developers rebuild each component from a picture and the picture wins arguments it should lose.
  3. Coded but not documented, so nobody knows a component exists and it gets rebuilt anyway.
  4. No versioning story. A change to a shared component that breaks a product nobody tested is how teams learn to stop upgrading.
  5. No contribution route. If the only way to add a component is to wait for the platform team, product teams will simply not use the system.
  6. Owned by nobody. The most common failure, and the one that turns an asset into a liability.

Budgeting it honestly

If you decide to build one, price the maintenance alongside the build - a meaningful fraction of someone's time, indefinitely. A system is a product with internal customers, and products without maintenance do not survive.

Then measure the thing it is supposed to improve. Not how many components exist, which measures effort. Measure how long a new screen takes to build, how many accessibility defects reach production, and how much of the interface actually uses the system. If those numbers do not move within two quarters, the system is not paying for itself and it is worth saying so out loud.