Designers directly control only the system image; the user's model can only be influenced indirectly

What it is

What a designer can directly adjust is the concrete material that makes up the system image — the interface, the documentation, the prompts. Whatever model eventually forms in a user's head is something the designer has no direct channel to reach. The user's model is a product the user derives on their own, taking the system image as raw material and running it through their existing experience, familiar analogies, and whatever attention they happen to be paying at the time — a derivation process that happens entirely outside the designer's control.

That means "I designed this feature to work this way" and "the user will understand this feature this way" are always separated by a layer of uncontrolled processing. The most a designer can do is make that layer more likely to land on the intended result — never guarantee the result itself.

Why it happens

What happens between system image and user's model is an inference that draws on prior knowledge, not a plain transfer of information. Hand the same system image to someone who has never used a comparable product and to a seasoned user, and the derived models can differ completely — the former can only work from the material in front of them, while the latter reads the new material through a framework built from prior products. The material is identical; the processing differs; so does the outcome.

Designers tend to overlook this layer of processing precisely because, when a designer looks at the system image, the design model is already sitting in their head as background knowledge — everything they see gets matched against it automatically, and it feels self-evidently clear. That vantage point is structurally unable to answer what someone who has never touched the design model would derive from the same material — a designer's understanding of their own work cannot stand in for the user's process of arriving at an understanding.

Studying it

Finding out what model a user actually derived can't be done by asking "do you find this usable" — it requires methods that externalize an internal representation:

• Prediction task: give the user an operation they've never tried, have them state their expectation before executing it, then compare the prediction against the actual outcome. The pattern of mismatch reveals which part of the model is wrong.
• Teach-back: have the user explain, in their own words, how the system works to someone else. Whatever simplifications, omissions, or invented causal links show up in that explanation are direct evidence of the model's content.
• Diagramming / structured description: have the user sketch how the parts of the system relate to each other. This suits structural, non-linear understanding (data flow, permission scope) and tends to expose the overall shape of a model better than plain Q&A.

Common independent variables: how the system image is presented (whether an explicit explanation exists, how detailed it is), the user's level of prior experience. Common dependent variables: prediction accuracy, the number of incorrect statements surfacing in a teach-back, how closely a structural description matches the actual architecture.

In interface research this method set is commonly used to verify whether a design change actually communicated the intended conceptual model — before shipping, run the same tasks against versions with and without an explicit explanation and compare the resulting models.

Methodology note: these tasks demand considerable time and cognitive effort from participants, who may organize their answers more carefully than they would in an actual, unprompted use context simply because they know they're being tested. Measured model accuracy can therefore run higher than the model a user would casually form in real use, so read the numbers with that discount in mind.

Where it stops holding

• A designer's adjustments to the system image can only shift the probability distribution over which model forms — never lock in one specific outcome. However clear an explanation is, some users will still derive an understanding the designer never anticipated, based on their own experience.
• This lack of control isn't distributed evenly: the sparser a user's prior experience (a first encounter with this category of product), the more their derivation sticks to the literal content of the system image, giving the designer relatively more leverage; the richer a user's experience, the more an existing framework intrudes, and the less leverage the designer has.
• This entry covers the existence of this layer of indirect relationship between designer and user's model — it does not cover whether the system image is internally coherent. Whether internal contradictions exist, and how they arise, is a separate matter.

Applying it

• Reframe the question when evaluating a design decision: instead of "did this clearly express what I meant," ask "what would someone with no background knowledge, seeing only this material, derive from it." Only the designer can answer the first question — which is exactly why it's unreliable.
• For concepts that are highly structural and can't be directly observed from a single interaction (permission scope, sync boundaries), relying on implicit presentation alone carries the highest risk, because these are exactly the concepts that leave the most room for a user's own derivation — and the most room for error.
• How to check: periodically run prediction tasks or teach-backs with real users, and lay the derived model side by side with the design model. Wherever the discrepancies cluster is exactly where the system image most needs reinforcement — a finding that self-review by the designer cannot substitute for.

Related

• Same group: A7.08.1 The system image is assembled from interface appearance, documentation, error messages, and word of mouth · A7.08.2 A self-contradictory system image produces inconsistent, even self-contradictory, user models · 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 · design model · mental model elicitation · teach-back · prediction task