Consistency
Adapted from the Cognitive Dimensions of Notations framework (Green & Petre, 1996; Blackwell & Green, 2003). See About the Dimensions for framework references.
Consistency means that similar semantics are expressed in similar syntactic forms — after learning part of the system, users can predict the rest. When a system is consistent, patterns learned in one area transfer to another. When it is inconsistent, every new feature is a fresh learning challenge, and users cannot rely on their accumulated knowledge.
The CXUX visual design section already covers the principle that consistency is a sliding scale, not an absolute — and that clarity should take priority when consistency and clarity conflict. This Harmonics dimension focuses on the evaluation and testing angle: how to identify where inconsistency is causing real problems, and where apparent inconsistency is actually serving a purpose.
Three Layers of Consistency​
Consistency operates at multiple levels, and they can conflict:
-
Internal consistency: The same actions and patterns behave the same way across the application. If Ctrl+D duplicates in the viewport, it should duplicate in the node editor too. If right-click opens a context menu in one panel, it should in all panels.
-
Domain consistency: Matching the conventions of the professional domain, even when they differ from generic software patterns. If every 3D application in the industry uses "S" for scale, a new 3D tool should follow that convention — even if it conflicts with another internal pattern.
-
Platform consistency: Following the conventions of the operating system or platform. On macOS, Cmd+, opens preferences. On Windows, Ctrl+S saves. Breaking these deeply learned patterns has a high cost.
When these layers conflict — when internal consistency would require breaking domain conventions, or domain conventions clash with platform standards — there is no universal answer. The guiding question is: which inconsistency will cause users the least confusion and the fewest errors?
The Consistency Trap​
Over-consistency can be as harmful as inconsistency. When everything looks and behaves identically, users lose the visual and behavioural cues that distinguish different types of elements. A dropdown that behaves identically whether it selects a colour, a blend mode, or a file format obscures the meaningful differences between those operations. Purposeful inconsistencies — affordances — signal that something is different and deserves different treatment.
Guessability​
The practical test of consistency is guessability: if a user learns how feature A works, can they correctly guess how the similar feature B works? If they can, the system is consistent in the way that matters. If they guess wrong and make an error, the inconsistency is causing real harm.
Testing​
- Pick an interaction pattern the user has learned (e.g., how to rename, duplicate, delete, group) and test whether it works the same way across all areas of the application. Note where it doesn't.
- Ask users to predict how an unfamiliar feature works based on their knowledge of similar features. If they predict incorrectly, investigate whether the inconsistency is justified or accidental.
- Check whether domain conventions are honoured — particularly keyboard shortcuts, terminology, and workflow patterns that users will bring from other tools in the same professional domain.
- Look for places where over-consistency obscures meaningful differences between elements or operations.
Conclusion​
Consistency is a tool for reducing learning burden and error rates, not a goal in itself. The question is never "is this consistent?" but "does this inconsistency cause confusion or errors?" Sometimes the most consistent choice is the wrong one, and a purposeful inconsistency better serves the user.
Check After Improvement​
- Error-Proneness
- Closeness of Mapping