Conceptual model

Designer’s model and user’s model

Donald Norman’s The design of everyday things popularized the terms designer’s model and user’s model (mental model):

The design model is the designer’s conceptual model. The user’s model is the mental model developed through interaction with the system. The system image results from the physical structure that has been built (including documentation, instructions, and labels). The designer expects the user’s model to be identical to the design model. But the designer doesn’t talk directly with the user—all communication takes place through the system image. If the system image does not make the design model clear and consistent, then the user will end up with the wrong mental model.

However, the concept was first introduced in the 1984 paper User Technology: From Pointing to Pondering by Stuart K. Card and Thomas P. Moran:

However, from the beginning, we were aware that methods are not sequences of meaningless actions, but that expert users also have an understanding of what the procedures cause the machine to do. That is, the expert users have some sort of mental model of what is happening inside the computer (“how-it-works” knowledge).

The first AIP memo in 1974 proposed the notion of the “user’s model,” which refers to a conceptual model that the user can have of the system. A user’s conceptual model is distinct from (but related to) the designer’s implementation model. It is an abstraction of the system’s architecture and software structures—the conceptual entities that the architecture and software implements—that is simple enough for non-technical users to grasp. (For example, a user might not know how the mechanism of the delete buffer of a text-editor works, but would simply know that the deleted text goes into a “clipboard.”) A user’s model would typically include knowledge of where information is stored (core memory, local disk files, remote file servers). It is important for the user to have an understanding of these kinds of features, for they are often not visible to the user.

Designing a conceptual model vs. communicating it

Daniel Jackson criticizes Donald Norman’s explanation for focusing on the “communication” of already designed conceptual models and emphasizes the importance of “designing” conceptual models (The Essence of Software):

To Norman, however, the conceptual model principle is mainly about communication: that the appearance of a device should convey its conceptual model. My view in this book is closer to Card and Moran’s: that the shaping of the conceptual model is itself the primary design challenge, and the problem of conveying it (or, in my terminology, mapping the concepts to a concrete user interface) is secondary.

Differences between the two perspectives:

Norman’s diagnosis of the refrigerator’s design problem is subtly different from mine. His primary concern is that the refrigerator does not convey the conceptual model effectively, and so the user’s mental model and the actual model are inconsistent. My objection, in contrast, focuses on the conceptual model itself: the design would still be bad even if the controls were accurately labeled.

To Norman, operating the refrigerator is an example of the “surprisingly large number of everyday tasks” for which “the difficulty resides entirely in deriving the relationships between the mental intentions and interpretations and the physical actions and states.” His language is revealing, and points to his origins as a psychologist: indeed, Norman’s book was originally titled The Psychology of Everyday Things and was only later renamed The Design of Everyday Things. The incompatibility he sees is between a physical world (that seems immutable the way he describes it) and the more malleable world of “mental intentions and interpretations,” which can be shaped by the user interface.

In my analysis, while the user’s difficulty may reside in the psychological gulf between mental model and physical mechanism, its resolution resides somewhere else: in the design of the refrigerator’s concepts, which are simply not fit for purpose. The user’s purposes—adjusting the temperatures of the fresh and frozen compartments—exist independently of any mental intention, and it is the fundamental misalignment of purposes and concepts that makes the design bad. This is not to say, of course, that Norman fails to recognize the troubling design of the refrigerator itself, and wouldn’t prefer a design with better concepts, but that his work has focused more on identifying the psychological barriers to usability.