Previous | Table of Contents | Next |
4. THE USER MODEL
A user model is the model the designer attempts to convey to the user through the user interface. It consists of the tasks, objects, operations, relationships, and the underlying concepts that tie them all together. User scenarios describe the sequences of user actions needed to accomplish a task. As with the essential model, the user model does not include anything about how a person interacts with the application or how the application is presented.
There is a temptation to design the user interface directly from the essential model; however, this is usually not possible since the actions specified in use cases are at such a high-level functionally that they typically cannot be accomplished by a single user action. In addition, the essential model does not necessarily have any underlying conceptual basis. Without this conceptual basis, a user must learn how to use the application by rote and remember it rather than using the underlying concepts to regenerate action sequences when needed, to solve problems, and to make educated guesses about how to perform unfamiliar tasks. As a result there is often a large gap between the essential and user models that the designer can attempt to bridge in several ways:
The author has a strong bias toward creating user interfaces based on metaphors. Over time, people have developed relatively efficient methods for dealing with commonly occurring situations. Ideally, these typical solutions are easily recognized, reducing the need for training, but even in those situations where a metaphor is not widely known among potential users it can still provide the structure of a time-tested solution. It has been the authors experience that once a metaphor has been selected, the user model can usually be fleshed out quite rapidly. The metaphor also provides a structure that can be easily extended to incorporate new requirements as they arise.
4.1. SELECTING A METAPHOR
A list of candidate metaphors can be generated by matching up elements of the essential model with things our target users already know about. The best place to start is to look for parallels to the objects, tasks, and terminology of the scenarios and use cases. Users will often use terms in their descriptions that are not part of the current environment yet somehow better convey how they think about it. If no obvious metaphors can be identified this way, the designer can always fall back on the basic metaphor of the physical world and concrete objects, assigning concrete representations to objects in the essential model that respond to similar kinds of actions.
The appropriateness of each of the candidate metaphors is tested by restating the objects and tasks of the essential model in terms of the metaphor. Not everything may fit exactly, but small differences can be ignored at this point. If a metaphor fits the essential model reasonably well, some trial user scenarios can be generated by restating the primary use cases in terms of the metaphor. These scenarios should still be functionally oriented, free of interaction specifics. This process or restating should be reiterated, using the metaphor as a guide to add details, until each task seems to be atomic, i.e., it seems likely that the user will be able to perform the task with a single action. This process will likely identify new, metaphor-specific objects needed by these atomic tasks. The metaphor is checked further to see that it provides the information needed to perform each task and ways of dealing with the problems that have been identified. What additional problems and limitations might the metaphor introduce?
Some simple sketches should be drawn that illustrate the trial user scenarios using metaphor-based visuals and the styles of presentation and representation common to other applications on the target platform. The intention is to get a feel for how the metaphor might be presented, not to define the user interface. This activity should be repeated with several alternative metaphors. The generation of several alternatives at each step is an essential part of the design process.
A metaphor seldom fits exactly right so some adjustments may be necessary. Parts of the metaphor may not be needed, although these unneeded parts may indicate missing functionality in the proposed application. More typically, parts of the scenarios cannot be mapped into the metaphor. Perkins, Keller, and Ludolph (1996) suggest that a metaphor can be extended in plausible ways by adding functionality that people wish existed in the real environment from which the metaphor is drawn. For example, the physical world imposes limitations such as an object can only be in one place at a time. A plausible extension would allow two geographically separated people to see and work on the same object on their computer displays while talking on the phone.
The preferred metaphor should be reviewed with the developers illustrating the primary user scenarios with a couple of line drawings or short storyboards. The intent is to keep the developers informed, giving them adequate time to consider implementation problems that might arise rather than surprising them later. It is the developers who will bring the design to life.
At this point the basic user model has been defined by remapping objects in the essential model and restating some of the use cases into the metaphor. The rest of the user model can be fleshed out by restating the rest of the use cases, making necessary adjustments to the metaphor, and generating the task tree (described below).
Previous | Table of Contents | Next |