UX rules and system consistency
🎧 Listen to every article back to back
A good user experience does not come from every screen being individually beautiful. It comes from all screens belonging together.
Users do not read design documentation. They learn as they go: I click here, this happens. Once a pattern works the same way in ten places, they expect it in the eleventh. When something different happens there, there is a small shock. Enough of those shocks and trust is gone.
Three levels of consistency
Visual consistency
This is the most visible layer — colours, fonts, buttons, icons, spacing.
Visual consistency does not mean everything must look the same. It means differences are intentional and meaningful. A red button signals a destructive action. A large gap marks a topic boundary. When the same visual difference appears without meaning, it becomes noise.
Rules:
- Every visual distinction must correspond to hierarchy, status or action type
- Different variants of the same component must be systematic, not arbitrary
- The colour scheme must work even under contrast requirements (accessibility)
Behavioural consistency
How things respond — on click, on hover, while loading, on error.
Users build a quiet mental model: "search works like this on this site". If search behaves one way in one section and differently in another, they have to rebuild the model. That is exhausting.
Rules:
- Similar actions must produce similar results regardless of context
- Feedback (hover, focus, loading, success, error) must be consistent across the system
- Animation speed and character must be coherent — not different on every page
Verbal consistency
Words, labels, error messages, confirmations — all copy as a system.
If a button says "Save", a modal says "Confirm" and a toast says "Changes applied" — all three mean the same thing, but the user does not know that immediately. They have to decide whether these are the same or different actions.
Rules:
- One concept = one word, always and everywhere
- User perspective first — not "Are you sure?" but "Delete this order?"
- Error messages must not describe the technical problem — they must say what to do
Achieving consistency in practice
Design tokens
Consistency starts with a token system. Not "this button is #2563EB" but "this button uses color-primary". When a meaningful change arrives — a brand update, an accessibility requirement — one place changes and everything follows.
Recommended token layer structure:
- Primitive tokens →
#2563EB - Semantic tokens →
color-primary,color-interactive - Component tokens →
button-bg-color
A component uses a component token. A semantic token defines meaning. A primitive token gives value. This way the primitive can change without breaking semantics.
Component library
Every recurring UI element must be a component — not a "similar" component but the same component. When a designer creates a new variant of an existing component, the question to ask is: does this new variant replace the old one, extend it, or is it actually a new component?
That question prevents component proliferation — the state where a library has 14 slightly different cards and no one knows which to use when.
Documentation as a product
Rules that only the designer knows are not rules — they are personal style. Consistency requires rules to be written down, findable and understandable by developers, editors and marketers alike.
Good documentation does not describe what exists — it explains why it is that way, and when an exception is valid.
Exceptions
Consistency is not an absolute rule. Sometimes there is a good reason to do things differently:
- Special context — a checkout flow may be intentionally simplified so the user understands they are in a dedicated process
- A/B testing — temporary divergence for a conversion experiment
- Different user groups — an admin interface and an end-user interface can be intentionally different
An exception is an exception only when it is a conscious decision with a reason. Without a reason, it is not an exception — it is a mistake.
Consistency and speed
A common fear: systematic thinking slows things down. In practice the opposite is true.
Consistency speeds things up:
- A developer uses an existing component rather than writing a new one
- A designer solves a new need within the system rather than from scratch
- A user learns one pattern that unlocks the whole logic — every new page feels familiar
Only building consistency is slow — the early steps when the system does not yet exist. That investment pays back quickly.
Summary
System consistency is not an aesthetic preference. It is a functional requirement.
Users trust a system that behaves predictably. They can do more, think less, make fewer mistakes. A team building a systematic interface moves faster, creates fewer duplicates, breaks fewer things.
Consistency is quality infrastructure — invisible when it works. Painful when it does not.
Need Drupal help?
If the article describes your situation, you do not have to read everything first. A real person will help you choose the next step.