The most dangerous moment in design systems work isn’t when the system is too loose. It’s when it’s too tight. A system that standardises too little produces the problem everyone recognises: inconsistency, drift, the Frankenstein product where every module looks like it was designed by a different team in a different decade. A system that standardises too much produces a quieter, harder-to-diagnose problem: a product that looks consistent but feels wrong.
Both failures are real. Only one of them gets discussed.
When a design system team sets out to fix inconsistency, the instinct is to standardise everything in sight. Every component gets a single approved version. Every interaction pattern gets documented and mandated. Every deviation becomes a violation to be corrected.
This instinct comes from a good place. Inconsistency is genuinely costly — it increases cognitive load for users, slows decision-making in design reviews, and creates maintenance debt that compounds over time. The case for standardisation is real and well-evidenced.
But the instinct to standardise everything treats all variation as the same problem. It doesn’t. There are at least three kinds of variation in a product, and they require different responses.
Accidental variation is the kind that happens when two designers solve the same problem independently and arrive at different answers. A filter interaction that works one way in the analytics module and a different way in the reporting module — not because the contexts are different, but because nobody compared notes. This variation is unambiguous. Standardise it.
Contextual variation is the kind that reflects genuine differences in workflow, user type, or information density. A table component that works at one density for a summary view and a different density for a detailed analysis view isn’t inconsistent — it’s appropriate. Flattening it into a single standard produces a component that serves neither context well.
Exploratory variation is the kind that appears when a team is working at the edge of what the system has addressed. They’ve encountered a problem the system doesn’t have an answer for, and they’ve made a local decision. Sometimes that decision is wrong and should be standardised away. Sometimes it’s right, and it should be promoted into the system as a new pattern.
Two designers solved the same problem independently and arrived at different answers — not because the contexts differ, but because nobody compared notes.
Genuine differences in workflow, user type, or information density. A dense analytical table and a summary card table serve different needs.
A team working at the edge of what the system addresses has made a local decision. May be wrong (standardise away) or right (promote to pattern).
A design system that can’t distinguish between these three kinds of variation will standardise the second and third as aggressively as the first. The result is a system that’s technically consistent and experientially brittle.
Before any standardisation decision, one question cuts through most of the noise: Does this variation force the user to relearn, or does it reflect a difference in context that the user would reasonably expect?
Variation that forces relearning is a problem. A user who learns how filtering works in one module and then encounters a structurally identical filter that behaves differently in another module has to do cognitive work they shouldn’t have to do. That work accumulates. It slows task completion, increases error rates, and erodes trust in the product’s coherence [1]. Standardise it.
Variation that reflects context is information. A dense analytical table and a summary card table are different surfaces serving different user needs. If they look and behave identically, one of them is wrong. The variation isn’t the problem — treating it as a problem is.
This question sounds simple. In practice, it requires the design team to have a shared, explicit understanding of what “context” means for each surface in the product. That understanding rarely exists by default. It has to be built — usually through the audit process that should precede any standardisation effort, not follow it.
One of the most useful standardisation decisions is also one of the least glamorous: don’t fix everything at once.
Full retroactive standardisation — updating every existing surface to comply with the new system — is appealing in principle and destructive in practice. It pulls engineering resource away from shipping new value. It introduces regression risk across surfaces that were working. And it creates a false equivalence between surfaces that need urgent attention and surfaces that are fine as they are.
The alternative is forward-only standardisation: new and modified surfaces follow the system from day one. Legacy surfaces converge progressively, prioritised by user impact rather than by proximity to the last design review.
This strategy accepts short-term inconsistency in service of long-term coherence. It focuses the system’s energy where it has the most leverage — on the surfaces that are actively being developed — rather than spreading it thinly across everything that exists. The psychological benefit is underrated. A team trying to standardise everything simultaneously is always behind. A team with a forward-only strategy has a clear, achievable definition of what “done” looks like for any given sprint.
When a design system standardises too aggressively, the costs are diffuse and slow-moving. They don’t show up in a single broken component or a failed usability test. They accumulate across thousands of micro-interactions where the system’s answer was close but not right.
A component clearly derived from the system, applied to a context the system wasn't designed for. Spacing right, colour right, behaviour subtly wrong.
Designers stop making judgment calls and start checking compliance. Design reviews evaluate whether something follows the spec, not whether it's right.
Teams facing legitimate edge cases accumulate one-off decisions outside the official framework — an undocumented shadow system.
The most common symptom is pattern mismatch: a component applied to a context the system wasn’t designed for. The spacing is right. The colour is right. The behaviour is subtly wrong for this specific use case. The user can’t articulate what’s off. They just know something is.
The second symptom is designer passivity. When a system is over-specified, designers stop making judgments and start checking compliance. The system becomes the answer to every question, including questions the system wasn’t equipped to answer. Design reviews shift from evaluating whether something is right for the context to evaluating whether it follows the spec. Those are different conversations, and the second one is less useful.
The third symptom is exception proliferation. When the system is too rigid, teams that encounter legitimate edge cases have two choices: force their use case into an inappropriate pattern, or request an exception. Over time, the exception list grows until it becomes a shadow system — undocumented and inconsistent in exactly the way the system was supposed to prevent [2].
The most useful framing for a design system isn’t a library of components. It’s a decision support layer — a shared reference that helps teams make good decisions faster, in situations the system anticipated and in situations it didn’t.
That framing changes what the system needs to contain. Not just components and tokens, but reasoning. Not just what to use, but when and why. Not just the approved pattern, but the logic that produced it — so that when a designer encounters a context the system hasn’t addressed, they have enough of the underlying thinking to make a judgment call that’s consistent with the system’s intent even if it isn’t in the system’s documentation.
This is harder to build than a component library. It requires the system team to make their reasoning explicit, to document the cases they considered and rejected, to write guidance for the designer who’s mid-problem under deadline rather than the designer who has time to study every page. But it’s the only kind of system that survives contact with a complex, growing product. A system of components breaks at the edges. A system of reasoning extends.
The best design systems teams have an answer to a question most teams never ask: what should this system not standardise?
Not as an admission of incompleteness. As a deliberate boundary. Some variation is load-bearing. Some differences between surfaces reflect genuine differences in user need, workflow context, or information structure. Standardising them away doesn’t improve consistency — it reduces fitness.
Knowing where to stop is as important as knowing where to start. A system with clear boundaries is more trustworthy than a system that claims to cover everything, because the team that built it has already done the work of distinguishing legitimate variation from accidental drift.
That distinction is the design system’s most important contribution. Not the component library. Not the token architecture. The shared understanding of which problems have been solved, which differences are intentional, and which questions still require judgment.
A system that standardises everything is as broken as one that standardises nothing. The value is in knowing the difference.
References