Previous Table of Contents Next


4.3. BUILDING A MODEL FOR THE USER

Any interactive computer system expresses an underlying model on the screen through words and/or graphics. The model consists of the objects and actions available, any sequencing of object use, and the navigation mechanisms available. This model will be called the system model here. The system model represents the designer’s understanding of the application and the user’s work.

When working with an interactive computer system, users form a (mental) model of the objects and actions available to them including how the system works, i.e., which objects and actions to use, and in what sequence, in order to accomplish a task (Norman, 1986; Preece et al., 1994). This (mental) model will be referred to here as the user’s model.

When users begin to work with a system for the first time, they try to match the objects and actions they know from their work/tasks to the objects and actions they see on the screen, i.e., they try to match their (mental) model with the system’s model. As part of their model, users determine how to navigate within the system: where to find objects and actions and how to activate them. If there is a good match between the system’s and the user’s models, then the system is intuitive and users will be able to complete a task on the first attempt with little help, and they will quickly progress to mastering the use of the system. If, on the other hand, the system’s and user’s models do not match well, users will have difficulty completing a task on the first attempt and will require frequent help.

The user’s model of the current application should be preserved in the system model of the revised application to the greatest degree possible in order to minimize learning when migrating to the redesigned version. The user’s model of the current application is discovered as part of the current task definitions (see Section 3.3), and the malfunction analysis of the current application identifies problems with the user’s current model. Measuring against usability performance objectives provides reliable data about the quality of the new system’s model.

This section describes the four project tasks involved in building a system model appropriate for the users:

  Design and use of metaphors (Section 4.3.1).
  Design decisions on task vs. object orientation in the system’s model (Section 4.3.2).
  Horizontal user interface design first: design of the opening screen, navigation principles, and principles for displaying objects (Section 4.3.3).
  Vertical user interface design second: design for each task (Section 4.3.4).

Some tips for managing design iterations are provided in Section 4.5, and some suggestions for documenting the design are contained in Section 5.

Within each of these four project tasks, there are several tightly coupled design/prototype/evaluate iterations, and there are also some iterations between them. For example, discoveries in individual task design may lead to modifications of the opening screen or the navigation techniques, causing some rework in these earlier project tasks. A frequent source of such causes for partial rework are ommissions of objects and functions that allow users to manage all their tasks in an efficient manner, e.g., to look up the status of an application, or to mark the progress of certain aspects of their work.

4.3.1. Design and Use of Metaphors

Frequently, an object in a system’s model or even the entire system’s model is described by a metaphor (i.e., an analogy to the real world) such as a desktop, a receipt, a list, or a shop floor (Carroll et al., 1988; Preece et al., 1994). The metaphor may be represented through words on the screen, e.g., appropriate screen/field/widget titles, or the metaphor may be represented pictorially, e.g., through icons or graphics. For example, an alphabetical list of customer names can be represented through words by a drop-down list box or pictorially by the graphical representation of a rolodex or a box of index cards. In each case, the underlying object is an alphabetical list of customer names, but the metaphor chosen to represent the object is different (note that a “list” is also a metaphor...). When designing metaphors, it is important to separate the metaphor from its verbal or pictorial representation on the screen. The method used to represent the metaphor on the screen (i.e., through words or pictures or a combination of both) is influenced by the underlying technology and the time available for development.

The author’s experience has been that, for the redesign of legacy systems, the detailed graphic representation of metaphors (folders with tabs, rolodexes, index cards, etc.) is less important than identifying the appropriate objects themselves and the grouping of objects according to steps in a task. In usability evaluations, it was found that users rarely noticed the detailed graphical representations, i.e., the graphical representations did not help the users find the correct object for a step in a task. When the objects were poorly structured, the detailed graphical representations actually interfered with task performance, and when they were brought to the users’ attention, the representations did not improve users’ understanding. Users thought of groups and sequences of screens as representing a task and its associated objects and actions.


Previous Table of Contents Next