System image (Donald Norman)

What the research shows

• Norman's framework separates three distinct things: the design model (the conceptual model held by the designer), the user's model (the mental model a person develops through use), and the system image — what the built artifact actually projects, including its physical or digital structure, its behavior and feedback, its labels, and its documentation.
• The system image is the only communication channel between designer and user. Designers and users rarely meet; whatever the design model contains that the system image does not express is, for practical purposes, unavailable to the user.
• Documentation, instructions, labels, warnings and even marketing material are described as part of the system image, not as something outside the product. In this account, a manual is one of the carriers of the conceptual model rather than a separate artifact bolted on afterwards.
• Norman's related constructs in the same body of work — the gulf of execution and the gulf of evaluation, affordances and (in the 2013 revision) signifiers, feedback and mapping — describe the mechanisms by which a system image either supports or obstructs model formation.
• Mental models formed from a weak system image are typically incomplete, partly superstitious and surprisingly stable. Norman's often-cited thermostat case (drawing on Willett Kempton's work on folk theories of home heating) illustrates how users adopt a plausible but wrong model — the dial as a valve controlling rate of heat — when nothing in the system image contradicts it.

Evidence status

• The system image is a theoretical construct from cognitive engineering, not a measured variable. It was proposed as an analytic distinction in Norman's 1986 chapter and popularized in The Design of Everyday Things (1988, revised 2013); there is no single experiment that confirms or refutes it, and it is normally assessed by how well it organizes observations.
• The empirical weight behind it comes from adjacent research: studies of naive and expert mental models of devices and physical systems, error research, and usability studies showing systematic mismatches between what designers intend and what users infer. Those studies support the general claim that interaction cues shape inference; they do not quantify a system image.
• Scope limits matter. The framework says nothing about how much documentation is appropriate, which medium works best, or how long a model persists. It also cannot be operationalized as a checklist: two products with equally complete system images can still differ in comprehensibility because of prior knowledge, domain conventions and language.
• Terminology has shifted. Norman himself revised his use of "affordance" and introduced "signifier" in later work, and "conceptual model" is used in the literature both for the designer's model and for the model a design presents — readers should check which sense an author means.
• The framework does not support the popular claim that "people don't read documentation." The opposite reading is closer to the source: instructions and labels are counted as part of the system image, and observed non-reading is treated as evidence about the cues and the situation, not as a fixed trait of users. It equally does not support the idea that a good interface removes the need for safety information or for instructions required by law.

Design model vs. system image

The design model is private: it lives in specifications, architecture decisions, and the heads of the people who built the thing. The system image is public: it is the sum of what the artifact and its accompanying information actually make perceivable. A team can hold an elegant, coherent design model and still ship a confusing system image — for instance when the terminology in the UI, the API reference and the user guide diverge. Conversely, a technically messy implementation can project a clear system image if its interface and documentation express one consistent conceptual model. Reviewing a product therefore means inspecting the image it projects, not the intentions behind it.

How it applies

For documentation work, the system image explains why wording, labels, screenshots, error messages and topic structure belong to the same communicative object: readers assemble one model out of all of them, so a term that means one thing in the UI and another in the guide leaves a contradiction the reader has to resolve. The practical techniques — expressing a conceptual model explicitly, aligning UI and documentation terminology, writing feedback-oriented troubleshooting, and minimalist instruction — are defined in the glossary Applied cognitive psychology for information use; this entry only describes the underlying account of how people infer a model from what a product shows them. None of it substitutes for a risk assessment or for the safety and instruction content a product is required to carry.

External references

• Donald A. Norman, "Cognitive Engineering" (1986), in User Centered System Design — publication record and DOI 10.1201/b15703-3
• Mental models — The Glossary of Human Computer Interaction, Interaction Design Foundation (summarizes Norman's design model / user's model / system image distinction)
• Mental models — The Decision Lab reference guide (entry on the term "system image")