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 designers understanding of the application and the users 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 users 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 systems 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 systems and the users 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 systems and users models do not match well, users will have difficulty completing a task on the first attempt and will require frequent help.
The users 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 users 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 users current model. Measuring against usability performance objectives provides reliable data about the quality of the new systems model.
This section describes the four project tasks involved in building a system model appropriate for the users:
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 systems model or even the entire systems 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 authors 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 |