When not to build one

Systems slow down the first three screens

Building tokens and components before you know what the product is means deciding things you cannot yet decide. The first three screens take longer, and several of the decisions turn out to be wrong, and unpicking them costs more than making them fresh would have.

This is the part that published design-system advice rarely says, because that advice comes almost entirely from organisations with dedicated system teams, hundreds of screens and dozens of contributors. Their conclusions are correct for their situation and are routinely applied to situations a hundred times smaller.

Where the breakeven sits

Two triggers, either of which is enough:

The same decision has been made three times. Three buttons drawn separately, three card layouts, three spacing choices for the same relationship. Three is the point at which the next one is cheaper to systematise than to repeat — before that, you are guessing at what the pattern will be.

A second person joins. The moment more than one person is making the decisions, the cost of disagreement exceeds the cost of writing them down. A solo designer holds the system in their head and it works; two people holding two systems in two heads does not.

Before either trigger, the correct amount of system is: a spacing scale, a type scale and a colour ramp, which cost half an hour and pay back immediately. Those three are always worth it. Components, documentation and governance are not, yet.

Projects that should not have one

• A one-off poster, flyer or invitation. It will be made once.
• A single landing page. Consistency within one page is achieved by looking at the page.
• An unvalidated product, where the screens will be thrown away. Systematising a design that is about to be replaced is work performed on a thing that will not exist.
• A prototype meant to answer a question. Its job is to be tested, not to be maintained.

In each of these, the three scales are still worth having and everything beyond them is overhead.

A system is a product with users

The cost that surprises people is not building it but keeping it. A design system has users — your own team — and like any product it needs:

• An owner. Somebody whose job includes it. Without one it becomes nobody's, which is the commonest way systems die.
• A way to request changes, and a decision about who says yes.
• A changelog, so people can tell what changed and when.
• A deprecation path, because components do get replaced and the old ones have to be removed rather than merely discouraged.
• Migration work, which is real and is usually underestimated. Changing a token's value touches every screen using it, and somebody has to check them.

A rough figure for a small team: maintaining a modest system costs the equivalent of a day or two a month, indefinitely. That is affordable and it is not free, and budgeting zero for it is why so many systems are abandoned within a year of launch.

The failure that ends most systems

One person builds it, in their own time, because they care. It is good. They leave, or move team, or get pulled onto something urgent.

Nobody else understands the conventions, changes stop being made, the product moves on, and within six months the system describes a product that no longer exists. People stop consulting it, which is rational, and then it is genuinely dead.

The defence is unglamorous: keep it small enough that somebody else can hold it, document the decisions rather than only the outputs, and make sure at least two people have made changes to it.

The opposite cost

None of this is an argument against systems. At two hundred screens with no system, every change is a hunt, every new screen is an argument, the product looks like five products, and onboarding a designer takes months.

That cost is larger than the maintenance cost, considerably, and it arrives whether or not anybody budgeted for it.

The judgement

Match the system to the project:

one artefact            three scales, nothing else
one page                three scales
a small product         three scales + six components + one page of notes
a product with a team   the above + a gallery + an owner + a changelog
many products           tokens in a neutral format, governance, versioning

Most readers of this course are in the first three rows, and most published advice is written for the last. Knowing which row you are in is the whole skill, and building a row-five system for a row-two project is a common and expensive mistake that looks like professionalism while it is happening.