Previous Table of Contents Next


Table 10.4 Detailed Design Documentation from an Information Perspective
Recommended
Information Display Object

(or Information
Required Type Resolution Coding)

Tank level Variable w/ precise value 0–400 cm Vertical gauge
Pressure is dangerously high Binary “Is dangerously high”, “is not dangerously high” Annunciation (Level 2)
Filter method being used Discrete Method1, method2, method3, <none> Highlight (using a box)
Plant state Discrete Shutdown, normal operation, abnormal, emergency Annunciation, state diagram

You may notice that the Recommended Display Object for “filter method being used” is actually a type of Information Coding (rather than a graphical object). Guidelines on types of information coding to be used would be found in the Information Coding design guide. This design guide presents recommendations for the use of visual and auditory coding in an interface. Visual coding techniques include color, shape, magnitude, positioning, texture, flashing, and alphanumerics. Though I developed such a design guide specific to our power plant design environment, more general guidance is abundant in the Human-Computer Interaction literature (e.g., Banks and Weimer, 1992).

Using a table such as Table 10.4 encourages documentation of the design process. Others can now refer to the tables I’ve created (in coordination with the design guides) to find out why I chose a particular display object. In some cases, I would give a choice of two or more recommended display objects.

In the idea-sketching phase, I arranged the location of rough user elements on a prototype. Now I am able to fill in the details with specific graphical objects and information coding choices, to create what I could legitimately call a screen design. This could be done in the context of higher-fidelity computer prototyping, if desired.

3.5. CONSOLIDATE PERSPECTIVES

Think of the sketches that have been created as though they have been etched on thin sheets of glass, by the divergent bands of light from the prism. Now take these sheets of glass and place them one on top of the other, as though you were overlaying transparencies on an overhead projector. In places, the four different views will complement one another and the pieces will fit together as a whole. In other places, there will be incomplete overlap and the resulting image will be cluttered and obscured. It is in these sections that you must eventually erase one or the other of the images, if your interface is to appear as a single, clear image. These sections are the alternatives, and you would like to choose the best of these images for your design. You can do so by testing these with users to see which alternative would be clearest, or which fits best. In the end, you should find that there are fewer holes in your design than if you had simply shone light directly through a single sheet of glass, rather than through the prism and its etchings.

By this point, I will have created at least four design sketches (one from each perspective) for the particular task I am studying. I am now faced with several possibilities. The designs can be amalgamated, so that the best of each is represented in an overall, cohesive prototype, or it may be desirable to leave the sketches separate, to provide alternatives for usability testing. It is likely, however, that a middle road will be taken. Most often, there will be ideas and elements in one perspective that are not captured in any of the others. There will also be some ideas in one perspective that contradict the ideas in another, so that it is not possible for the two to coexist in a single interface. As a result of the choices I make in consolidating design perspectives, I might end up with one task that is represented by an Information perspective, while the next might be an amalgamation of the Goals and Action perspectives. Still a third task might be the synthesis of idea sketches from all four perspectives. The consolidation process is illustrated in Figure 10.9.


Figure 10.9  Consolidating perspectives

At the same time as I was designing for individual tasks, other members of our human factors group were working from the top-level, using their own methods to design the interface from above.7 We were taking simultaneous top-down and bottom-up approaches. There is a danger in this — of having to redesign large parts of the interface if they don’t mesh. However, an element of risk often accompanies design attempts, and this particular risk is accompanied by at least two positive features. First, this way of doing things can easily be more time and resource efficient. Two groups can work from different directions at the same time. Second, it again supports the multiple-perspectives approach. If we did come up with different solutions (from top and bottom) that did not mesh, then in the process we would have provided ourselves with a new set of alternatives to test with our users. For the sake of conservatism, communication between the two groups can help offset the risks.


7I have not yet tried designing the overall, high-level structure of an interface using the Design Prism method, but there is no reason why the method couldn't be used for this purpose. For instance, the overall structure of a power plant control room could be design from the perspective of the Information that an operator needs to run it. This might lead to an annunciation-centered control room. On the other hand, if the overview were designed again from the perspective of Actions, this might lead to an input-based control room. Consolidate the two and you get a typical modern control room.

The consolidation stage is an important time to test alternatives with real users of your system. End users are the ones who can best tell you which design works for them. They can help you to decide which perspective, or combination of perspectives, your final design should take.


Previous Table of Contents Next