Inconsistency across screens compounds complexity beyond the simple sum of each screen's own complexity

What it is

If every screen in a product looks simple on its own, but terminology, navigation, and control meanings are inconsistent from screen to screen, the total load a user carries can exceed what you'd get by adding up each screen's complexity individually. That extra load doesn't come from any single screen — it comes from the inconsistency between screens: when moving between contexts, the user can't simply carry over the operating pattern they just learned, and instead has to re-check whether this screen follows the same rules as the last one. This is why a product's overall complexity can't be estimated by scoring each screen separately and summing the scores.

Why it happens

Understanding a screen relies heavily on analogy to screens seen before — the same icon should mean the same action, a control in the same position should behave the same way. This analogy saves effort because it replaces "relearn how this screen works" with "confirm this screen matches what I already learned," which is far cheaper cognitively. Once inconsistency appears between screens — the same icon means "delete" on one screen and "archive" on another, the same gesture triggers different actions on different pages — the analogy fails or actively misleads: the user not only has to relearn the current screen's rules, but also has to actively suppress the rule they just learned on the previous screen that no longer applies here. This extra suppression work is produced purely by the inconsistency itself, and it never shows up in any single screen's complexity assessment — it can only be measured by looking across screens together.

Studying it

A common approach has participants use, in sequence, multiple screens within the same product that differ in terminology, navigation structure, or control meaning, completing a task that spans those screens, and compares total completion time, total error count, and the rate of a specific error type — "operating the current screen using the previous screen's rule" — against a fully internally consistent set of screens.

Common independent variables: the degree of consistency across screens in terminology, navigation, and control meaning; the number of screens involved. Common dependent variables: total time and total errors on the cross-screen task, the rate of specific "rule misapplication" errors.

This comparison is often used in HCI to evaluate the overall usability of large products or products built by multiple teams — individual pages might each pass a usability test on their own, but walking through a flow that strings several pages together often reveals problems rooted in inconsistent rules between pages, not any single page's flaws.

Methodological note: this effect can only be measured through a cross-screen continuous task; usability testing each screen separately won't reveal it. A test flow specifically designed to span multiple screen transitions is needed.

Where it stops holding

• If the interval between a user's use of two screens is long (say, several days apart, with a lot of unrelated activity in between), the cross-screen analogy itself is less likely to happen, and the extra load from inconsistency weakens accordingly.
• This entry concerns the compounded load produced by inconsistency itself; it does not address what standards or processes should be used to maintain consistency — that is a matter of team coordination and implementation practice.
• If the inconsistency only occurs between two screens that users almost never encounter in the same session (entirely non-overlapping use contexts), the actual chance of an analogy conflict is small, and this effect's impact is markedly reduced.

Applying it

• When assessing the complexity of a multi-screen product, don't just run a usability test on each screen separately and add the results. Design a dedicated task that spans multiple screens and watch for extra hesitation or errors at the screen transitions.
• Keep the same icon, the same gesture, and the same terminology carrying exactly the same meaning across all screens in the product; if a screen genuinely needs to assign a different meaning, use a clearly distinct visual presentation to avoid it being mistaken for the same rule.
• Verification: track where and how often the specific "operating the current screen with the previous screen's rule" error occurs during cross-screen tasks. If these errors cluster at transitions between screens with inconsistent terminology or control meaning, cross-screen consistency in the current product carries a real load cost that should be fixed first.

Related

• Same group: A9.05.1 Element count is not cognitive load · A9.05.2 A dense but well-structured interface can beat a sparse but chaotic one · A9.05.3 Hiding structure behind a simplified appearance raises load · A9.05.4 Objective structural complexity and subjective perceived complexity don't always track together, and can vary independently · A9.05.5 Visual complexity metrics correlate weakly with actual cognitive load · A9.05.7 A more aesthetically pleasing interface is often misjudged as easier to use, masking real differences in load
• Nearby: A7.08 Design model, system image, and user's model
• Search terms: consistency debt · cross-screen complexity · interface consistency