Consistency is not uniformity

Two things that sound alike

Consistency means the same things look the same. A destructive action is always the same colour; a card always has the same radius; a section heading always has the same space above it. This is what lets a reader stop examining, and it is the property that makes every deviation meaningful, as the repetition lesson established.

Uniformity means everything looks the same. It is what you get when a system is applied without judgement, and it produces work that is competent, coherent and completely inert — no hierarchy between screens, no sense that any moment matters more than another, nothing an eye wants to land on.

A system is meant to produce the first. Left unsupervised, it produces the second.

When breaking the system is correct

Four situations, and they are narrower than most people would like:

1. A moment that must not feel routine. An irreversible deletion. A payment confirmation. The completion of something that took the user an hour. These should look different from the ordinary flow, because feeling the same as everything else is precisely the failure.

2. A genuinely new content type. The system has no pattern because nothing like this has existed before. Build the new thing, use it, and then decide whether it becomes a pattern.

3. A different audience or context. A marketing landing page and the product's settings screen have different jobs. Sharing tokens is right; sharing every component is not. Most organisations run a looser system for marketing and a stricter one for the product, and that is a reasonable arrangement rather than a failure of discipline.

4. A deliberate experiment. Testing whether a different treatment performs better. This is a break with an expiry date attached.

What is not on the list: this screen felt boring, and the designer wanted to do something interesting. That is the uniformity complaint, and the answer is usually that the hierarchy is flat rather than that the system is wrong.

How to break it without dissolving it

Three conditions, and all three matter:

• Deliberately. Somebody decided, and can say why.
• Documented. The exception is recorded where the system lives, so the next person knows it was a choice.
• Resolved. Within some agreed period, the exception either becomes a pattern or is removed. Exceptions that are neither are how a system decays.

That third condition is the one that gets dropped and the one that determines whether the system survives two years.

The signs of drift

Systems fail gradually and the symptoms are recognisable:

• People copy and detach components rather than using them.
• A component's usage count stops growing while the number of screens grows.
• Values appear that are not in the scale, in increasing numbers.
• Somebody maintains a private stylesheet of overrides.
• New joiners ask which of these two patterns should I use, and get different answers.

Each of these is information rather than misbehaviour. People route around a system when it costs them more than it saves, which means a system nobody uses is usually a system that was too strict, too incomplete or too hard to find — not a team that lacks discipline.

The response to drift is an audit and a conversation, not an instruction.

Over-strict is a real failure mode

This is worth saying because the literature is overwhelmingly about the opposite risk. A system that forbids everything produces designers who spend their effort negotiating rather than designing, and work that is worse than it would have been with no system at all, because the constraints were binding in the wrong places.

The symptom is that people are asking permission for things nobody should need permission for — a one-off illustration, the exact crop of a photograph, the wording of a label.

A good system constrains the things that benefit from consistency and says nothing about the rest. Spacing, colour, type and component behaviour benefit enormously. What a photograph depicts, how an illustration is drawn, and what a headline says do not, and a system that governs them has overreached.

The periodic audit

Once a quarter, or whenever it feels wrong, do the three audits from earlier blocks together: every distinct spacing value, every distinct type size, every distinct colour, plus every component and its usage count.

The list is the conversation. Values that appear once get deleted or adopted. Components used once get merged or removed. Exceptions get resolved.

An hour, four times a year, is what keeps a system from becoming a document describing a product that no longer exists.