by Diane Wilson, Thyra Rauch, and Joeann Paige

The following article is drawn from a number of sources at the ACM CHI '92 conference. It is the third in a series.

Generating ideas for graphical user interfaces isn't like anything else in software design or development. There are no simple, foolproof guidelines; neither are there any structuring paradigms that lead to any sort of true enlightenment. It requires a disparate set of skills, including software engineering, graphic design, and psychology, but the mere assemblage of the necessary talent and skill (not likely to occur in one person) is insufficient for success.

One element which is frequently missing is a thorough understanding of the problem domain. As with low technology prototyping, we can include this knowledge by inviting prospective end users, technical writers, and market specialists to join the design effort. But once we have the right people to do the job, what tools do we need in order to accomplish the task?

One of the necessary tools is task analysis. There is simply no substitute for a detailed understanding of the work to be done, in the form of scenarios that describe the tasks from beginning to end, and a task structure chart that shows:

• who performs each step
• each step's starting point and goal
• the information necessary to complete the step
• the assumptions that define the context of the step.

Another useful tool is the Decision Support Center, an electronic conferencing environment that allows many people to share and develop ideas simultaneously. Its limitation, however, is that its current implementation doesn't allow sharing of graphical or iconic ideas; nor does it convey the tone or body language that allow us to assess approval, agreement, comprehension, or other intangibles that simply don't come across in words on a display screen. It also penalizes slow typists.

So we still have no complete substitute for seating people around a table and asking them to talk to each other. Are there ways to structure their interaction to speed up the process? Yes, and low technology prototyping tools provide some possibilities. But they are primarily tools for developing and evaluating ideas; what we need are some brainstorming tools to generate ideas of a very specific kind. You might think of this as "structured brainstorming."

The idea of "structured brainstorming" isn't as much of an oxymoron as it might seem. The prototyping techniques we will discuss here share important attributes with brainstorming, including quick generation of many ideas and non-judgmental evaluation. The purpose of structure in these activities is to encourage ideas to be expressed in particular forms that are relevant to key aspects of design of graphical user interfaces--metaphors and icons.

Before attempting either of these techniques, it is vital to have a completed task analysis for the problem to be solved. It is also critical that participants read and understand the task analysis. Task analysis is a point of departure for design; if doing the task analysis is included in these design activities, it will take too much of the focus, and you will not have time to get on with the brainstorming. It is entirely possible that the task analysis will grow and mature as a result of these brainstorming techniques, but that's to be expected.

The remainder of this article deals with generating metaphors. Brainstorming for icons will be covered in the next article of this series.

An Update on Metaphors

Apple's User Interface Guidelines states, "Use concrete metaphors and make them plain, so that users have a set of expectations to apply to computer environments." That's easy to say, but how do you select a metaphor? How do you know that it's appropriate, without first implementing it? It's interesting to note that one of Apple's major success stories is the desktop metaphor for the Macintosh; yet Apple's own research shows that few users think of the Macintosh display as a "desktop."

The best approach for developing a metaphor is to collaborate with prospective users--a metaphor, after all, is a tool to link your product to the user's mental model.

To understand how we use metaphors to communicate, consider the following sentence: She walked with heavy mechanical steps.

If you found this sentence in a romance novel, you might conclude that she has just seen her boyfriend in the arms of another woman. Or perhaps a man, whose attention she doesn't want, has trapped her in a compromising situation.

If you were reading a mystery, several possibilities might occur to you. She might have found a dead body. Does she know who the murderer is? Perhaps she has killed someone. Maybe she has discovered that someone hates her enough to kill her, and intends to do precisely that. (Of course, she might also be a red herring. Mystery writers do that.)

A science fiction reader would draw the immediate conclusion that she has heavy mechanical legs. But other questions would occur: Why such crude technology? Doesn't she feel trapped or diminished by her situation?

Writers build stories out of details and subtleties and indirections. Metaphors play an essential role in creating a world, an atmosphere, a context in which the action occurs. This is part of the mental model of the writer. But what of the mental model of the reader? The reader will know what kind of book he or she is reading, and will interpret clues accordingly. The writer must anticipate this, and build in clues--using metaphors, props, internal dialogue, and more--that the reader will interpret properly, using the reader's own mental model. The reader cannot share the writer's mental model, so the writer must adapt to the reader.

In other words, a writer cannot construct an artifact that is independent of its context and usage. The same thing is true in mathematics; Kurt Gödel proved (with his Incompleteness Theorem) that it is impossible to create a closed system that does not depend on some knowledge of the world outside of that system.

So it is with software design; users have a mental model that filters anything and everything we give them in an application. Metaphors provide a powerful way to communicate with the user, to link the mental models of the developer and the user. By itself, software can only be incomplete; it is useful and usable only within the external contexts of user and task.

Metaphors can play different roles in different contexts and at different times.

• Explicit metaphor: A user interface design technique for presenting software in a way that takes advantage of users' previous domain knowledge and experience (for example, a "window" into a document).
• Implicit metaphor: A tool for helping designers to understand users and their tasks; a way for the two groups together to explore different and new aspects of the tasks; a source of novel ideas and inspiration. These metaphors are used in the design process but are not represented in the resulting interface. An example of an implicit metaphor would be to consider a message system in terms of a railroad, in order to understand queuing, routing, and so on.

Explicit metaphors have certain risks. They must be concrete and obvious in order to be effective. They must be appropriate to the task; otherwise, they mislead and confuse the user. Some tasks do not have an appropriate metaphor. An incomplete metaphor can lead to the user's taking the metaphor more seriously than the designer intended.

As the user uses a metaphor to mesh his or her mental model with an application, the metaphor may lead to misunderstandings about the capabilities of the software. This happens when the user attempts to apply the metaphor to problem solving; designers must understand and anticipate this. One proposal is that interface design should be considered as a matter of two distinct mental models:

• Interaction mechanics. This is the surface of the interface, its operational characteristics. The desktop and the equivalence between finger-pointing and direct manipulation are examples of this.
• Task domain. This includes the operations, objects, and relationships within the application. In complex applications such as word processing or drawing, the task domain is clearly beyond the scope of a desktop or window metaphor, but can be accessible through a desktop metaphor--and controlled through the direct manipulation metaphor.

Metaphors can be both limiting and liberating. R. B. Smith, in describing the Alternate Reality Toolkit, defines "the tension between literalism and magic":

Literal features are defined to be those that are true to the interface's metaphor. Literal features enhance an interface's learnability. Magical features are defined to be those capabilities that deliberately violate the metaphor in order to provide enhanced functionality.

A metaphor may be intentionally incomplete and also have "magical" qualities. This can result from conscious and valid choices, as well as from an inability to implement a complete metaphor. Consider the difference between a restaurant menu and a computer menu. A restaurant menu uses graphic design principals to direct the eye through the submenus for various courses of a meal, as well as through major groupings such as classes of entrées. On the other hand, the dynamic nature of a computer environment allows menus to adapt--automatically, or through user actions--to context, to the user's experience level, or to specific user preferences.

Because of these complexities in mapping metaphors to tasks to user interfaces, Alan Kay prefers the term user illusion, because it is the magic that matters. If a computer did nothing more than to imitate the limitations of the real world, it would be a useless exercise to do anything at all with a computer. If a piece of paper in a painting metaphor were as hard to erase as real paint on real paper or canvas, who would bother? And what about hypertext--where is the real-world metaphor to support that bit of magic?

Does any of this mean that metaphors are useless? No, we only need to remember not to be slaves to them, and not to enslave the user to them. We need to recognize their limitations and their richness, and we need to be explicit about their boundaries. We may need multiple metaphors to understand, embody, illustrate, and animate our concepts. And we must understand and accept that users will extend our metaphors beyond our intentions and expectations.

Where IBM's Common User Access (CUA) discusses metaphors, the examples are design elements (such as an out basket for an electronic mail system), rather than single metaphors that try to encompass an entire interface design. This kind of self-limiting use of metaphors helps designers to focus their thinking; in turn, this focus helps users understand both the magic and the limits of the metaphors we choose to express openly.

The Metaphor Game

Roger von Oech states, "Metaphors are effective in making complex ideas easier to understand. Indeed, they can be good tools to explain ideas to people outside your specialty." This applies to designers, who may need to explain system concepts to end users, and also to end users, who must explain their tasks and work environment to designers. The Metaphor Game applies this concept directly; it is a form of structured brainstorming in which ideas are expressed and developed in the form of metaphors.

How does this work? Look back at our discussion of fiction-writing techniques and mathematics. We used these as metaphors for the software development process, to demonstrate the technique of metaphorical thinking, as well as to make a point about the linkage between developer, product, and user.

Prior to beginning the game, the moderator makes up a set of 10 to 20 task cards, based on the elemental tasks from the task analysis. Two to eight participants then shuffle the cards and deal them out. Next, the participants evaluate the tasks, either grouping related tasks together or setting aside tasks that are unrelated to the others. High-level tasks--those with multiple subtasks--are broken down into elemental tasks, and the new tasks are written on blank task cards. These new task cards are then evaluated and grouped together along with the original cards.

When this phase is complete, participants name the task groups by consensus. Task group names can be written on the task cards, or the moderator can write group names on a Task Board and use children's stick-ons (teddy bears, beach balls, and so on) to identify related tasks.

In the next phase, players "free associate" on the elements of a familiar place or activity--a candidate metaphor for the problem domain. The moderator can seed a specific metaphor, or the group can choose one from a list of "starter" metaphors. Reasons for choosing particular metaphors may vary; they can be either obvious or apparently unrelated to the problem. Or the choice can be completely random. At this point in the game, each group can make its own rules, so metaphors can be discarded and replaced as necessary.

After the group decides on a metaphor, players take turns naming the components, characteristics, or activities relating to the metaphor. They write these on attribute cards, which should be a different color from the task cards.

The following table gives a few example metaphors, along with various types of attributes. These can be seeds for the metaphor game or examples to start participants thinking about the characteristics of their own choice of metaphor.

Two things might happen during this phase of the game. Participants may think of other tasks in the problem domain, based on their exploration of the metaphor. They might also begin to think of mappings between attributes and tasks, but these should be held privately until the next phase begins.

As the attributes are recorded, players set their attribute cards on an attribute board. When the metaphor exploration is finished, the players shuffle the attribute cards, deal them out, and group them as they did with tasks in the first phase. As with the tasks in the first phase, they may discard attributes that don't fit in groups with any other attributes.

The final phase is to map the metaphor attributes to the tasks from the problem domain. However, if the group created any new task cards while exploring the metaphor, they should pause to organize these cards into groups with the original task cards.

During the mapping phase, each player takes a turn mapping one attribute to one task. If the group agrees to the match, the cards are paper-clipped together and placed on the "mapping board." As before, it is always fair game to create new task cards or new attribute cards. Remapping of tasks and attributes is always appropriate when better matches are found. Players should try to be consistent about mapping families of tasks with groups of attributes; this consistency provides the predictive power when the user exploits the metaphor while exploring and using the finished product.

The Metaphor Game is still an experimental technique, but one that shows promising results. Early experience indicates that the task identification phase helps the group understand the problem domain. But it might take too much time from the "fun" part of the game and might also create too much of a formal, analytical atmosphere for effective brainstorming. One solution is to hold the task identification phase a day or two before the metaphor exploration, but using the same players.

Depending on the personalities in the group, it might be necessary to seed the game with metaphors that are appropriate to their experience and outlook. Another alternative is to play the second and third phases more than once, starting with an "easy" metaphor and proceeding to more interesting ones.

But the benefits of the Metaphor Game are clear: it is fun, it fosters creativity, and it builds understanding of both the problem and the means to express a solution.

References:

1. Apple Computer, Inc. Human Interface Guidelines: The Apple Desktop Interface. Reading, MA: Addison-Wesley, 1987.
2. Card, Orson Scott. Characters & Viewpoint. Cincinnati, OH: Writer's Digest Books, 1988.
3. Hofstadter, Douglas R. Gödel, Escher, Bach: an Eternal Golden Braid. New York: Basic Books, 1979.
4. Information Development Guideline: Task-Oriented Information, ZZ27-1971. Mechanicsburg, PA: IBM Corporation, 1991.
5. Kay, Alan. "User Interface: A Personal View." Laurel, Brenda (ed.), The Art of Human-Computer Interface Design. Reading, MA: Addison-Wesley, 1990.
6. Muller, Michael J., Wildman, Daniel M., and White, Ellen A. Games and Other Techniques for Group Design of User Interfaces. New York: ACM, 1992. (CHI '92 tutorial)
7. Smith, R. B. "The Alternate Reality Kit: An Animated Environment for Creating Interactive Simulations." Proceedings of the 1986 IEEE Computer Society Workshop on Visual Languages. Dallas, TX: IEEE Computer Society, 1986.
8. Systems Application Architecture: Common User Access Guide to User Interface Design, SC34-4289. Cary, NC: IBM Corporation, 1991.
9. Tognazzini, Bruce. Tog on Interface. Reading, MA: Addison-Wesley, 1992.
10. von Oech, Roger. A Whack on the Side of the Head. New York: Warner Books, 1990.

Copyright © 1992 by IBM Corporation. Published with permission.