The system image is assembled from interface appearance, documentation, error messages, and word of mouth

What it is

What a designer has in mind is the design model; what a user actually ends up believing is the user's model. The two never touch directly — between them sits the system image: the full sum of external evidence a user can actually get their hands on. That includes the interface's look and interaction behavior, but also help documentation, the wording of error messages, what the installer or marketing page claims, and even a friend saying "just tap here, that's how it works." All of that together is the system image — not just the screen the user happens to be staring at.

Whatever model a user builds is built entirely out of system-image material. There is no channel that bypasses it to reach the design model directly.

Why it happens

The system image is stitched together because it is never produced by one person at one moment: interface visuals and interaction are set by a design team, help documentation is often written by a different group, error copy may be added by an engineer in passing, the marketing page comes from yet another line of work, and whatever a user hears secondhand happens entirely outside the product team's control. Each of these fragments is produced independently, yet a user's mind treats them as evidence about the same single system and stitches them together — the "wholeness" of the system image is something the user's model-building imposes on it, not a property it already has.

Because these fragments arrive from different sources, at different times, through different hands, they don't automatically stay consistent — and a user has neither the ability nor the reason to weight them differently ("this line is from the official manual, that one is a friend's anecdote, so it should count less"). Once a fragment has entered the user's field of view, it becomes raw material for the model, regardless of who produced it or how reliable it is.

Where it stops holding

• Only what actually reaches the user counts. An internal design brief, an unshipped proposal, documentation for a feature that never went live — however accurately these reflect the design intent, they are not part of the system image if the user never encounters them, and they have no direct bearing on the user's model.
• The boundary of the system image shifts with the product's lifecycle. A redesign can leave behind old screenshots, a cached help page describing the previous version, or longtime users' accounts of old behavior — these "stale" fragments keep reaching new or returning users and remain part of today's system image even though they describe behavior the system no longer has.
• This entry only covers what the system image is made of, not whether its fragments agree with each other or which one carries more weight — those are separate layers.

Applying it

• Treat the system image as a checklist that needs active management, not something that's "done" once the interface is designed: list every category of fragment a user can encounter — onboarding, persistent status indicators, help-center articles, error copy, app-store descriptions, support scripts — and confirm each one falls under design review, rather than being maintained separately by teams that never talk to each other.
• Marketing pages and install flows are the touchpoints a design team most often overlooks; audit them specifically to confirm their claims about system behavior match the current implementation, rather than repeating language from a few versions ago.
• How to check: hand someone who has never touched the product every fragment you can collect — not just the interface itself — and ask them to describe what they think the system does; then compare that description against actual behavior. Almost every discrepancy traces back to one specific fragment, not to a vague "the user just didn't get it."

Related

• Same group: A7.08.2 Internal contradictions in the system image produce inconsistent, even self-contradictory, user models · 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 · design model · three-model framework · mental model construction