UX

UX rules and system consistency

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.

Subscribe via RSS
Kaido Toomingas Kaido Toomingas WebPro Company OÜ

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.

Contact us