Strive for consistency

What it is

Shneiderman's "strive for consistency," the first of the eight golden rules, calls for identical terminology, menu structure, colour coding, action sequences, and outcomes across similar situations within one product. Any difference between situations must be explainable to the user as a genuine functional difference, not an incidental wording choice by whoever built that screen. This rule governs internal consistency — whether the product should also match platform convention is a separate question, covered by "follow platform conventions," and the two should not be conflated.

Why it happens

Consistency works through learned transfer: once a user confirms that a given name, icon, or position produces a given result in one place, they generalise that rule to similar-looking situations instead of re-verifying every time. The cost structure here is not linear — it behaves more like a one-shot trust contract. The first confirmed exception makes the user stop trusting the rule anywhere it resembles the violating case, not just at that one control, so they fall back to memorising each case individually. What gets damaged is not the one inconsistent element but everything that looks like it — which is why a single inconsistency costs far more than "one bug": it poisons the user's predictability assumption for a whole neighbourhood of the interface, not just the offending spot.

Where it stops holding

Internal consistency can collide head-on with platform convention. A cross-platform product that forces one universal "back" gesture across iOS, Android, and the web runs straight into gestures users have already over-learned on each platform — iOS's edge swipe, Android's gesture or hardware back, the browser's own back semantics. The stronger, pre-existing learning curve wins: users apply platform habit to the "internally consistent" design, and that consistency becomes the actual source of errors. The workable compromise is to yield to platform convention at near-primitive layers — navigation, system gestures — and reserve internal consistency for product-specific vocabulary and business actions. A second boundary is historical debt: once an early, flawed metaphor is baked in system-wide, "staying consistent" simply means propagating that mistake. The fix there is a deliberate breaking migration, not using consistency as a reason to leave it alone.

Applying it

• Build a mapping table of objects, actions, states, icons, and terms, marking the standard wording, banned variants, and applicable platforms — and list "yielded to platform convention" exceptions separately so they are not mistaken for oversights.
• Reuse existing interaction contracts on new screens; where deviation is unavoidable, document the reason, how it is signalled, and the migration plan.
• Run a cross-module walkthrough comparing same-named objects and actions, and count the cases that cannot be explained with a single sentence. Wherever the collision is with platform convention, change the product's own rule first rather than asking users to override platform habit.

Related

• Same group: B3.11.2 Provide universal usability · B3.11.3 Offer informative feedback · B3.11.4 Design dialogs to yield closure · B3.11.5 Prevent errors · B3.11.6 Permit easy reversal of actions · B3.11.7 Keep users in control · B3.11.8 Reduce short-term memory load
• Nearby: B2.10 Consistency · B3.04 Consistency and Standards
• Search terms: golden rules · consistency · design standards