A product can have a design system and still feel inconsistent.
The buttons come from the same package. The colors exist in the same token file. The Figma library looks tidy. The component docs are well written. And somehow, after a few quarters, the product still starts to feel like five applications wearing the same jacket.
One page uses 16px spacing. Another uses 20px because it “looked better.” One team adds a custom card layout. Another wraps the modal component because the default API did not support one case. A loading state becomes a spinner in one flow, skeletons in another, and nothing at all in the third.
The usual response is predictable: add more components.
I don’t think that is always the problem.
Most teams do not need a design system because they are missing reusable UI pieces. They need one because their frontend decisions are leaking everywhere.
That is a constraint problem.
A design system gives teams reusable pieces.
A constraint system makes the right implementation hard to avoid.
A component library is not a system
I am not arguing against design systems.
Good design systems are useful. They create shared language. They reduce repeated work. They help designers and engineers move from “what shade of blue is this?” to “what state is this interaction in?”
But a component library alone is not enough.
A folder of Button, Input, Modal, and Card components is a catalog. It tells engineers what is available. It does not necessarily tell them what is allowed, what is preferred, what is deprecated, what is dangerous, or what will fail review.
That distinction matters.
If a team can use the official button component and still create a primary destructive ghost button with a custom color, custom padding, no loading behavior, and an icon without an accessible name, the component exists but the decision is still uncontrolled.
The system did not fail because the button was missing.
It failed because the invalid state was allowed.
Inconsistency survives when bad choices are easy
Frontend inconsistency rarely arrives as one big decision.
It arrives through small local choices that feel harmless at the time.
A designer asks for a slightly tighter section. An engineer writes a one-off margin. A page needs a layout the primitives do not support yet, so someone writes custom CSS. A deadline is close, so an accessibility requirement becomes a checklist item instead of an API default. A performance budget exists in a document, but CI never reads documents.
None of these choices look catastrophic in isolation.
The problem is that every team makes them differently.
That is how products drift.
The cost is not only visual inconsistency. It shows up in accessibility, performance, developer experience, and maintainability.
Engineers spend more time asking which pattern is correct. Reviews become subjective. Designers have to re-explain decisions. Platform teams become the cleanup crew. New features inherit old exceptions because nobody knows whether the exception was intentional or accidental.
At scale, “just use the component” is too weak.
The system has to narrow the path.
What constraint actually means
A constraint system does not mean making engineers powerless.
It means converting repeated decisions into defaults, APIs, checks, and review rules.
This is where design and engineering have to meet. Design defines the product language: hierarchy, intent, interaction patterns, density, motion, and accessibility expectations. Engineering turns the repeatable parts into APIs, tokens, primitives, checks, and release standards.
For example, design tokens are not constraints by themselves. A token file that exports space.4, space.6, and color.primary is only a menu. It becomes a constraint when raw spacing values are linted, token usage is expected in review, and layout primitives make the tokenized path easier than hand-written CSS.
The same applies to components.
A button API with unlimited combinations is flexible, but flexibility is not always a virtue. If every prop can combine with every other prop, the component is outsourcing design decisions back to every consuming team.
A better API reduces the valid states.
type ButtonProps =
| {
variant?: "default" | "secondary" | "outline";
size?: "sm" | "md" | "lg";
confirmLabel?: never;
}
| {
variant: "destructive";
size?: "sm" | "md" | "lg";
confirmLabel: string;
};
type IconButtonProps = {
icon: IconName;
"aria-label": string;
size?: "sm" | "md";
};This is a small example, but the principle matters.
A destructive action cannot silently use the default variant. An icon-only button cannot exist without an accessible name. If a destructive action needs confirmation, the API can force the caller to provide the copy.
That is a decision encoded in software.
Where design systems usually leak
The leaks are usually familiar.
Spacing tokens exist, but nobody has to use them. So teams write margin-top: 18px because the design looked close enough.
Layout components exist, but they are too rigid or poorly documented. So engineers bypass them with page-level CSS, and every page invents its own rhythm.
Accessibility guidelines exist, but the components do not enforce them. So IconButton can render without a label, Dialog can be opened without focus management, and form errors can exist visually without being connected to inputs.
Performance budgets exist, but only as good intentions. A route grows by 80KB, a hero image loses priority, a third-party script enters the critical path, and nothing blocks the pull request.
Documentation exists, but it describes components instead of decisions. It tells you how to import a modal, but not when a modal is the wrong interaction. It lists variants, but not the product meaning behind each one.
This is why “we have a design system” can become misleading.
The visible library may be real. The constraints may not be.
Enforcement is part of the design
The practical version of this is not mysterious.
Raw color values can be blocked with Stylelint or a custom ESLint rule. Token usage can be encouraged through typed theme access instead of arbitrary strings. Component variants can be modeled with TypeScript unions instead of boolean prop soup. Accessibility defaults can be verified with Storybook interaction tests, Playwright, or axe-core.
Performance can be treated the same way.
If a route-level JavaScript budget matters, put it in CI. Use something like size-limit, Lighthouse CI, bundle analysis, or framework-specific build checks. If above-the-fold images matter, make image priority and dimensions part of review. If a shared layout component controls the first viewport, make layout shifts visible before they reach production.
The tooling can vary.
What matters is whether the rule has weight. A rule feels different when it can fail a build, fail a test, or slow down a review.
A documented standard says, “Please remember this.”
An enforced standard says, “This is how we ship.”
The better system has fewer valid choices
Strong systems are not strong because they contain every possible option.
They are strong because they reduce unnecessary choice.
A good frontend platform gives teams a smaller decision surface:
Use these spacing tokens. Use these layout primitives. Use these semantic component variants. Use this loading pattern. Use this error pattern. Use this form API. Use this page shell. Use this route-level performance budget. Use this escape hatch only when the product case is real.
That sounds restrictive until you work in a large enough codebase.
Then it starts to feel like speed.
Engineers do not need to debate margin scales on every feature. Designers do not need to inspect the same broken states repeatedly. Reviewers do not need to leave comments about the same accessibility issue every week. Platform teams do not need to reverse-engineer which exceptions were intentional.
The system carries the boring decisions.
That is the point.
Defaults matter more than documentation
Documentation is still important, but documentation is weakest when it carries rules that code could enforce.
If every dialog must trap focus, the dialog component should do it by default.
If every icon-only button needs an accessible name, the prop should be required.
If every page should use token-backed spacing, the styling layer and lint rules should make raw values visible.
If every route has a JavaScript budget, CI should check it.
If every image above the fold needs an intentional loading strategy, review standards and automated checks should make that part of the workflow.
Docs should explain why the rule exists, when to use the pattern, and what tradeoffs were considered. They should not be the only thing preventing the product from drifting.
A rule that lives only in documentation is a rule that depends on memory.
Memory does not scale.
Escape hatches should be explicit
Every system needs escape hatches.
Products have edge cases. Campaign pages happen. Experiments happen. Legacy surfaces exist. Sometimes the correct answer really is outside the default path.
The problem is not the existence of escape hatches. The problem is invisible escape hatches.
If a team can bypass tokens, variants, layout primitives, or accessibility defaults without leaving a trace, the platform cannot distinguish an intentional exception from a shortcut.
A healthy escape hatch is named. It is visible in code review. It has a reason. It is rare enough to inspect.
For example, an unstyled prop may be valid for composition, but it should not become the casual way to avoid the system. A raw CSS utility may be necessary, but it should be obvious enough that reviewers can ask why. A performance budget override may be acceptable for one route, but the reason should be attached to the change.
Escape hatches are pressure valves.
They are not back doors.
The system also has to learn
Constraints should not become a way to blame product teams for working around gaps.
If Stack and Grid exist but teams still write page-level flexbox wrappers for every feature, the primitive may be missing an important use case. If every product team wraps the same Modal component to support a common footer layout, the system is probably under-designed. If engineers keep bypassing spacing rules to match real screens, the token scale may not fit the product density.
That is where mature frontend platform work matters.
The answer is not to shame teams in code review. The answer is to inspect the escape hatches, find the repeated pressure, improve the primitive, and then make the custom path visible again.
Good constraints are not frozen.
They absorb real product needs without letting every product need become a permanent exception.
This is also a developer experience problem
Design consistency is often framed as a visual problem.
For frontend platform work, it is also a developer experience problem.
A weak system asks engineers to make too many decisions with too little context. Should this be primary or brand? Is this spacing allowed? Can I use this color? Is this modal pattern accessible? Do we lazy-load this chart? Is this route allowed to exceed the bundle budget?
When the system does not answer those questions, every feature rebuilds the same context from scratch.
A strong system turns common decisions into defaults and uncommon decisions into explicit choices.
That is the platform value: shared components matter, but the larger win is reducing decision cost across teams without lowering quality.
That requires architecture judgment. It requires understanding accessibility beyond checklists. It requires performance discipline beyond Lighthouse screenshots. It requires empathy for engineers who need to ship under deadlines. It also requires enough product sense to know when strictness helps and when it becomes ceremony.
The job is not to make rules for the sake of rules.
The job is to make the right path cheaper than the wrong one.
The best systems feel boring
The best frontend systems rarely look impressive from the outside.
They do not always produce flashy demos. Sometimes the most valuable work is a stricter prop type, a removed variant, a layout primitive that prevents twelve custom wrappers, a lint rule that blocks raw color values, or a CI check that catches a bundle regression before it reaches production.
That work can look small until it shows up in every feature shipped after it.
The hardest problems are rarely solved by adding one more component. They are solved by making repeated decisions disappear.
When teams do not have constraints, every page becomes a negotiation.
When teams have good constraints, consistency becomes the default behavior of the codebase.
That is the real promise of a design system.
Not more components.
Fewer unnecessary decisions.
A good design system should behave like a constraint system. It should make the approved path obvious, the unsafe path visible, and the invalid path difficult to ship.
Because reusable components do not create consistency.
Enforced decisions do.