A self-contradictory system image produces inconsistent, even self-contradictory, user models

What it is

The interface implies one behavior, the documentation states another, and an error message offers a third explanation — when different fragments of the system image conflict with each other, a user doesn't automatically pick out "the correct one" and settle on a single coherent understanding. A user can perfectly well hold two mutually incompatible beliefs at once, each triggered in a different situation, without ever noticing the conflict. This is different from a model that's internally coherent but wrong overall — here the model itself is not coherent to begin with.

Why it happens

Users usually don't encounter the different fragments of a system image side by side, in the same moment, in the same context: today a line in the settings page says one thing, weeks later an error message says something else, and the two are never directly compared. Model-building happens piecemeal, one encounter at a time — each time a new fragment shows up, a user tends to slot it into their understanding for that particular situation, without going back to check "did I once see the opposite claim somewhere," mostly because no one keeps a record like that, and there's no motive to cross-check a detail that hasn't caused trouble yet.

The result is a model that is locally coherent but globally inconsistent: in situation A, the user acts on the rule fragment A supplied, and things go fine; in situation B, the user acts on the opposite rule fragment B supplied, and things also go fine — until the boundary between the two situations is crossed, and only then does the user realize, for the first time, that they've been carrying two rules that contradict each other, a contradiction that never surfaced in any single prior use.

Where it stops holding

• A contradiction only shows up as an internal inconsistency in the user's model if the user has actually encountered both conflicting fragments, one after another. If the usage path only ever touches one side of the conflict, the contradiction stays at the level of the system image and never propagates into the user's model — the user experiences nothing unusual.
• A latent contradiction can persist for a long time: as long as the triggering condition (both situations becoming relevant at once) never arises, an internally inconsistent model can support normal use indefinitely, until some edge-case operation, a troubleshooting session, or a switch to a new device puts both sides in front of the user at the same time.
• This entry covers the consequence once a contradiction has propagated into the user's model (inconsistency, even self-contradiction) — not where the contradiction inside the system image originates. The source and composition of the fragments themselves is a separate layer.

Applying it

• Pick a handful of core concepts (whether an action is reversible, whether data lives locally or in the cloud, whether a given state gets synced) and, across every touchpoint a user might encounter — interface copy, help documentation, error messages, onboarding — check whether the claim about that same concept is consistent, rather than only checking that the interface is internally coherent.
• Prioritize the handoff points between teams, where contradictions most often creep in: documentation that wasn't updated after a design change, error copy still phrased around logic that engineering has since replaced.
• How to check: design a task path that walks a user through two related touchpoints in sequence (for example, reading a piece of guidance copy, then triggering an error), and watch whether the user's account of what's happening, or their behavior, shifts between the two encounters. A shift indicates an as-yet-undiscovered contradiction inside the system image.

Related

• Same group: A7.08.1 The system image is assembled from interface appearance, documentation, error messages, and word of mouth · A7.08.3 Designers can directly control only the system image; the user's model can only be influenced indirectly · A7.08.4 System image conveyed by word of mouth and peer demonstration can outweigh what the product presents on its own
• Nearby: A7.01 Definition and function of mental models · A7.10 Making the conceptual model explicit
• Search terms: system image · inconsistent mental model · contradictory model · mental model construction