Previous | Table of Contents | Next |
In most cases, the related elements listed in Table 10.3 will already have been identified earlier in the process. For instance, tank level was already listed under the Information elements available, so when it came time to define relations for the Goal control tank level, it was just a matter of noting that the two are related. In other cases, though, I identify new user elements while filling in the table. For instance, while completing the Information column, I realized that if the pressure is dangerously high, then the user may want to know: How long has it been dangerously high? and What is the cut-off level between dangerous and normal?.
Organizing the user elements in the table will sometimes also bring to light elements that were hidden or assumed. If, for instance, blank space is being used to convey information to the user, then this should be stated explicitly in the design model. Some information will inevitably be conveyed by location, whether this is a simple left-to-right hierarchy of importance, or some more complex form of coding. Reviewing ones prototypes from this point of view, to see what information is being conveyed by location, or color, or size, or shape, can be instructive.6 It may also highlight instances in which the information might better be conveyed in another manner.
6A further example of this can be found in Collura et al. (1989). They specified in a design that what they referred to as hot information would appear at the bottom of the screen, while cold information (such as status information or summaries) would appear at the top. Making this distinction between types of information is important, but a distinction such as this comes only by stepping back and explicitly identifying user information, if not from past experience.
The Table of Relations may appear to be a bit lengthy, but keep in mind that each table is completed for only one task at a time. It would, inarguably, be tedious to draw up a table for all user elements of an entire interface at one sitting. Instead, I draw up the table one task at time, then immediately move on to sketching ideas from each of the perspectives on that task. Only then do I start drawing up the Table of Relations for the next task. I find that this approach helps me to concentrate on one particular perspective at a time, and allows me to focus on and design separate alternatives in parallel.
3.4. PROTOTYPE EACH PERSPECTIVE
Next, I sketch preliminary design ideas from the perspective of each type of element. I might start, for instance, by designing a Goals-oriented interface based on the user elements in the Goals section of the Table of Relations. By following a similar process for each of the other three perspectives, I end up with a number of prototype ideas from four different perspectives.
3.4.1. Idea Sketching from Each Perspective
Let us assume, for instance, that we are designing the controls for the liquid levels in two tanks found in the power plant (see Figure 10.8). By designing from the perspective of Objects, we end up with two objects (Tank1 and Tank2), on each of which we can apply the action increase or decrease. However, when we design from the perspective of Actions, we find that we have instead designed a generic Increase/Decrease capability that works on either tank (depending which one is selected by the user). In the first case, the two tank objects became the key organizational features. In the second case, the actions were the key organizational features, and the two fluids (in the tanks) merely parameters upon which generic actions could be taken. This would be an excellent point at which to do an analysis of the trade-offs between the designs (whether via usability testing or an evaluation on the basis of some Human-Computer Interface design criteria).
Figure 10.8 Example prototypes from different perspectives.
I find that this method of design allows me to free myself from the constraints of a particular perspective (by forcing me to focus on four different perspectives), while I generate design ideas and solutions. Note, however, that some of the interface elements will be repeated across the sketches. Though I am designing from the perspective of one particular element at a time, I still put other element types into the interface as necessary, as long as they are within the focus of my perspective (e.g., in Figure 10.8 I use a tank object in the Action perspective because it falls within the focus of the design for that perspective). The user elements from other perspectives that do show up in the prototypes for the current perspective should be those elements that appeared in the Related Elements column of the Table of Relations (Table 10.3).
At this point, I tend to use only rough sketches of the design elements that are laid out as I would like them to appear in the interface. In the example, for instance (Figure 10.8), I presented a generic tank without measurement units or level markings. Similarly, if I needed to represent trend information in the interface, I might use a generic trend graph: in which axes would be labeled, but no scale given, and a generic line or curve would be drawn on the graph to represent the type of relationship.
3.4.2. Screen Design using Design Guides
Having drawn up some idea sketches from each perspective, I then want to resolve in detail how the objects will appear on the screen. I have again found it useful to draw up a table (such as the one shown in Table 10.4) for each task.
In Table 10.4, the Recommended Display Object for tank level (vertical gauge) would be defined precisely (and pictured) in a Graphical Display Objects design guide. This design guide illustrates and specifies, in detail, the properties of graphical objects to be used in the interface. Its purpose is to maintain consistency across the system and to reduce the need to redefine and redraw objects that have already been created. If an object wasnt in the Graphical Display Objects design guide, then the design guide would need to be updated to include the new object. For objects that are used only once or twice, however, it may not be worth the effort of including them in a design guide. In our power plant design, we drew up formal design guides for the use of all designers across the plant (who included both human factors specialists and software developers). In a smaller operation, something less formal would do.
Previous | Table of Contents | Next |