Interaction as System

An interface is not a collection of individual interactions. It is a system. The user who learns how one button behaves should not need to re-learn how every other button behaves. Consistency is the mechanism that makes interaction knowledge transferable.

What consistency means

Consistency means that the same type of action produces the same type of response, every time, everywhere in the interface. A primary button has the same visual treatment and behaviour in the header, in a modal, in a sidebar, and in a table row. A dropdown opens the same way in a form and in a toolbar. An error message uses the same format and placement whether it comes from a password field or a payment form. This consistency allows users to build a single mental model of how the system behaves — one model that transfers across every context.

The pattern library

Consistency at scale requires documentation. A pattern library — whether a formal design system or a documented set of components — captures the interaction behaviour of every component: its states, its keyboard interactions, its timing, its error handling. Without documentation, components diverge as different designers and developers make independent decisions. The visual inconsistency is easy to spot. The interaction inconsistency — a button that submits on Enter in one context and requires a click in another — is harder to see but equally damaging to the user’s model of the system.

Breaking consistency deliberately

Consistency is not uniformity. Some interactions are so high-stakes that they deliberately break the pattern — a destructive action that requires an extra confirmation step, an irreversible operation that demands typed confirmation. These exceptions are valuable precisely because they break the established pattern: the deviation signals to the user that this action is different, that it requires more care. Use pattern-breaking intentionally and sparingly.

The cost of inconsistency

Every inconsistency has a cost: the user’s model is wrong, they make an error, they lose confidence in the system, or they spend effort re-learning what they thought they knew. In large interfaces built over time by multiple teams, inconsistency accumulates until the interface feels unpredictable — users cannot trust that what they know in one area applies elsewhere. This is one of the strongest arguments for investing in a design system: not the visual consistency, but the interaction consistency.

The takeaway

Treat every interaction decision as a system decision — this is systems over instances applied to behaviour rather than visual tokens. When you decide how a control behaves, you are deciding how every instance of that control behaves. Document the decision. Apply it uniformly. Break it only when the break carries meaning. The goal is an interface where users stop noticing the controls and focus entirely on their tasks.

When to break this

Consistency reduces cognitive load. Intentional inconsistency raises it — which is sometimes exactly the point.

When you might break it:

• Destructive and irreversible actions — a button that deletes an account, sends a payment, or publishes to production should not behave like every other primary button. The friction imposed by a different pattern — a confirmation dialog, a typed confirmation, a secondary warning step — is the message: this action is different.
• Onboarding flows — new users benefit from a simplified interaction vocabulary that diverges from the main interface. Fewer options, larger targets, reduced state complexity. The exception is bounded: once onboarding ends, the main system takes over.
• Context-demanded adaptation — a dropdown with 200 options needs a search field that a dropdown with 5 options doesn’t. The underlying interaction concept (select from a list) is consistent; the implementation adapts to what the data requires.

If you do:

• Make the deviation obvious. The break should signal difference, not just be different. If a destructive action confirmation looks almost like every other dialog, users will dismiss it without reading it.
• Document the exception in your pattern library with the explicit reason. An undocumented deviation is indistinguishable from an inconsistency — future designers will “fix” it and remove the signal.
• Keep internal consistency within the exception: if typed confirmation is required for account deletion, it should be required for every equivalently destructive action, not just this one.

Consistency versus context is a named conflict in the Conflict Matrix — specifically the distinction between keeping behaviour consistent and letting visual expression adapt.