Mental Models, Metaphors, and Usability

Once you've gained a concrete understanding of how users approach their tasks, you can begin to understand the mental models associated with these tasks . A mental model is the set of thoughts and structures we use to explain, simulate, predict, or control objects in the world. It is shaped by the task and the tools used to accomplish it, which means that it can change over time. As far as I know, there is no language or notation that formally documents mental models. At best, mental models are informal observations that the development team can use to create more usable systems. Consider a designer creating a new project planning tool. Through several interviews she has discovered that managers think of dependencies within the project as a web or maze instead of a GANTT or PERT chart.

In creating the new planning tool, the development team will create one or more conceptual models to share their understanding with others. A conceptual model is some representation of a mental model, in words or pictures, using informal or formal techniquesfor example, a UML class diagram of the primary concepts in the system.

An understanding of mental models, and the clarifying role of conceptual models, forms the creative foundation of metaphors that can be used in the creation or modification of a system. Metaphors are models that help us understand one thing in terms of another. Tarchitects often use metaphors to structure their application architectures. In one system I worked on, we had to support message passing between distributed systems in such a way that any system in the chain could add data to or remove it from the core message without altering the core message contents. To help explain this concept to potential customers, I created the metaphor of a Velcro-covered ball, where the ball represented the core message and the data that customers could add to the message were "attached" or "removed" much like we could attach or remove pieces of Velcro to the ball.

A well- chosen metaphor shapes both the tarchitecture and the user interface. In the project planning example described above, the system's underlying tarchitecture could easily have one or more functions to manipulate project plans in terms of a web or a maze. This choice, in turn , could provide creative ways of organizing tasks, displaying information, or providing notification of critical path dependencies.

Metaphors are often most apparent when considering the marketecture, primarily because those chosen by a tarchitect must be communicated in a targeted manner to a well-defined market. Metaphors can influence a variety of brand elements, including names and iconic representations of products or processes. They often affect the pricing model, by highlighting areas of the system that are of greatest value to the defined market segment. Entirely new products rely on metaphor to both explain how they work and provide marketects with the vehicle for shaping future customers' mental models about them, how they work, and the benefits they provide. All of these are reasons for close collaboration between marketects and tarchitects in the development of the system metaphor. In the example of a project planning tool, the marketect may prefer the metaphor of a maze over that of a web because a maze better fits the product's positioning.

The final benefit associated with well-chosen metaphors, and arguably the most important reason to pursue them, is their effect on usability. They substantially improve system usability by tapping into users' existing mental models of their work and how that work should be performed. Training costs are substantially reduced, satisfaction improves , and overall comfort with the system increases . An excellent catalog of prospective metaphors can be found in Designing Object-Oriented User Interfaces [Collins 1995].