Superficial consistency with behavioral inconsistency is the worst case

What it is

When two elements look alike or use the same name, icon, and position but differ in click behavior, input, state change, permission, or result, there is behavioral inconsistency. This is more dangerous than obvious difference: surface similarity strongly invites people to transfer an existing rule, while actual behavior contradicts the expectation and produces confident, repeated error.

Why it happens

People classify objects by appearance and language, then invoke learned rules for that class. If identically styled buttons sometimes execute immediately, sometimes open editing, and sometimes do nothing, people learn their classification was wrong only after action. Repeated prediction failure erodes trust in all similar cues and leads to item-by-item probing or repeated confirmation. When differences involve publication, deletion, permission, or fees, errors can have material consequences.

Studying it

Build an audit list of “same cue, same behavior” covering primary paths and state variants: default, disabled, loading, insufficient permission, offline, error, and partial completion. Have people transfer from one example to a visually similar one, recording expectation, action, result, and recovery. Repeated clicks, frequent undo, and surprising paths around the same control in logs can also reveal hidden inconsistency.

Where it stops holding

Visually similar elements may genuinely need different outcomes because object permission or lifecycle differs. The difference cannot reside in implementation alone: it must be made explainable through state, labels, or feedforward. Conversely, visual difference need not imply behavioral difference if it does not break reasonable inference. The goal is not templated appearance, but alignment between visible and behavioral classifications—or explicit communication of the difference.

Applying it

• Define an interaction contract that same styles, names, and icons must preserve, and make state and permission differences part of component design rather than ad-hoc branches.
• Where behavior must differ, change labels, state, or feedforward enough to be noticed and understood, stating availability conditions and outcome.
• Prioritize edge states of similar elements in regression testing and experience review so new exceptions do not quietly break established expectation.

Related

• Same group: B2.10.1 Internal consistency means coherence within a product · B2.10.2 External consistency means consistency with platforms and similar products · B2.10.3 When consistency conflicts with optimization, evaluate transfer cost
• Nearby: B2.03.3 A wrong signifier is more harmful than none · B2.07.3 Feedforward and feedback should use the same expression system
• Search terms: behavioral inconsistency · false consistency · expectation mismatch