Previous | Table of Contents | Next |
3. DESIGNING FROM MULTIPLE PERSPECTIVES THE DESIGN PRISM
The literature on Human-Computer Interface design has historically maintained a focus on presenting alternatives to users. Lets look for a moment at what this asks of UI designers. It asks designers to develop more than one option in parallel. It asks them to do so while preferably still maintaining creativity and uniqueness between options. As individual designers, are we capable of meeting this demand?
To some extent, of course, designers are capable of pursuing multiple alternatives. However, it is my contention that we are restricted by a human tendency to reduce designs to single solutions. This process of funneling information can be indispensable as a human problem-solving technique, but it can also interfere with our ability to pursue more than one solution at any given time. As we adopt (both consciously and unconsciously) what appear to be the best choices at the time, we are simultaneously losing a myriad of other possibilities. The problem isnt simply that we forget that other options existed, but that our best solution begins to block out other alternatives so that we fail to even think of them in the first instance. We suffer from tunnel vision. Just as we have trouble dividing our attention in short-term cognitive tasks (e.g., Anderson, p. 52), I believe it is also difficult for the human mind to maintain a number of creative and distinct alternatives over long periods of time.
It is for the above reasons that I suggest an approach which looks at user data from several different perspectives and maintains these perspectives through the idea generation and initial prototyping stages.5 This imposes a structured methodology which forces designers into thinking about and creating distinct alternatives, without imposing restrictions on the creativity within each perspective. When funneling occurs, ideas are now channeled in four different directions ( instead of just one. Alternatives are pursued in parallel, up until the point where concrete designs can be reviewed by users.
5Another approach to preventing the loss of design alternatives is to carefully record unpursued alternatives and design decisions. While this is an important process (and I recommend it), it doesn't help with the actual generation of design alternatives themselves. In this respect, another alternate strategy would be to simply have more team focus in design. This might only succeed however, if team members were to work in isolation, since the same problem of losing alternatives is likely to occur for teams, as well as for individuals (i.e., groupthink).
I use the analogy of a prism to illustrate the design approach I have taken. Just as a prism splits light into a visible spectrum of color, so similarly I take raw user data and split it into distinct elements. The types of elements (or design perspectives) are user Information, Objects, Goals, and Actions. I create a table showing which elements in each perspective are related to which others. I then draw up rough sketches from each perspective (e.g., from the perspective of user Goals first). Finally, I consolidate these different views of the same problem. Depending on the nature of the task, this may result in a single best-of prototype or it may result in several distinct alternatives. These activities are illustrated in Figure 10.6.
Figure 10.6 Design prism activities.
3.1. DESIGN CONTEXT THE DESIGN PRISM
In the Design Prism work, where replication of existing plant functions was the focus, user requirements were represented by (1) a hierarchical breakdown of operating procedures for the plant, which provided the grounding for (2) a task analysis. We called the hierarchical breakdown a function analysis. It presented goal statements for operator activity. At the top of this hierarchy was a single, highest-level operator function: Operate the Plant to Setpoints, to Achieve Safety and Production Objectives. This top-level function was divided into six subfunctions. These sub-functions were each in turn divided and redivided, eventually creating a hierarchy intended to cover all operator functions that related to plant operation. At the bottom level, then, were individual, reasonably low-level goal statements. An example might be: Control Liquid Level in Boric Acid Storage Tank. These bottom-level functions became our individual user tasks for the task analysis.
The task analysis itself, then, needed only capture the timing and sequence of steps necessary to accomplish each of the bottom-level operator functions (individual tasks). The task analysis was also intended to cover branching and exception scenarios, where these were not already captured in the function analysis. The highly structured nature of the function analysis, with its clearly-defined individual user tasks, leant itself well to interface design on a piece-by-piece level.
Our user population consisted of operators of nuclear power plants. The following characteristics are descriptive of this population:
The Design Prism techniques described in this section were developed by me mainly as an individual designer, working on my own. Other members of a team of four to six Human Factors specialists were available for review and criticism of the work I produced.
A few of the individuals on the team were working on design from the bottom up, while the most senior designers were working on the overall design of the control room. The bottom-up designers, myself included, would work on design one task at a time. The product design can be characterized by:
Previous | Table of Contents | Next |