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. Let’s 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 isn’t 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:

  Extensively trained on the software we create.
  Can be considered very homogeneous, as a result of training and educational background.
  Interval company employees, or employees of a client company.

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:

  Fire-preventing, rather than firefighting.
  Emphasis on replicating existing design — providing computerized access to existing physical procedures in the plant.
  Design conducted mostly at a desk, with limited physical space.
  The interface, for critical safety reasons, cannot be too “open” (i.e., user choice is strictly limited, so that the interface presents discrete and known possibilities to the user; windows cannot overlap one another)


Previous Table of Contents Next