Smart Things: Chapter 3, Interaction Metaphors, Part 3: Designing with Metaphors

This is Part 3 of a pre-print draft of Chapter 3 from Smart Things: Ubiquitous Computing User Experience Design, my upcoming book. (Part 1) (Part 2) (Part 4)The final book will be different and this is no substitute for it, but it's a taste of what the book is about.

Last month I posted a draft of Chapter 1

Citations to references can be found here.

Part 3: Designing with Metaphors

Metaphors are complicated tools. They inspire us to make new associations and can communicate complex ideas quickly, but they also constrain thought. Connections that may make sense in the metaphor's source concept may not exist in the target. For example, Netscape's Navigator browser provided little guidance on how to reach a destination, like an actual navigator would. If its exploration metaphor is interpreted literally, browsers are more like boats, and search engines (which, coincidentally, little resemble engines from a user's perspective) are the navigators. As documented by Blackwell (2006), the history of metaphors in interaction design has gone through boom times -- the 1980s success of the desktop metaphor -- to times of extreme criticism and failure (the infamous Microsoft Office 97 paperclip). [Footnote: Blackwell (2006) is indispensable for those interested in the history and cultural role of metaphor in human computer interaction.] Despite the criticism, however, metaphors remain powerful and valuable tools. They are one of the most straightforward ways to tap into existing knowledge to create a familiar narrative out of novel functionality.

This chapter provides a set of benchmarks for thinking metaphorically about ubicomp UX design. If the assumptions behind a project recall one of these metaphors, it is possible to ask the following questions about the design metaphor as a way to understand the project's limits and possibilities -- and your own as a designer.

• What is the comparison that this metaphor is making? What class does it say that the design and the metaphor belong to?


• What is the list of tools and activities associated with the source concept? How would those map to the experience being designed?


• What are the visual images the source concept evokes? What are the interaction patterns that it implies? Are there necessarily positive outcomes to those patterns? Negative ones?


• What is the purpose of using the metaphor? What exactly do you need it to accomplish? What associations is it supposed to evoke and what actions will the metaphorical associations make easier?


• What are the boundaries of the metaphor? At what point do the differences between domains become so great that the metaphor hurts more than it helps?

Sidebar: Dan Saffer's Guidelines

The following guidelines from ubicomp designer Dan Saffer (2005) provide a sequence for approaching the design of interaction metaphors and designing with metaphors. It begins with a focus on the culture of use and ends with advice for identifying and discarding metaphors that are no longer valuable.

1. Metaphors are cultural. Different cultures have different conceptual frameworks, especially about abstract ideas like time. Be conscious of differences when picking metaphors that span multiple cultures. Not only are metaphors culturally specific, but they can also be limited to specific audiences within that culture. If you do not have a desktop, the desktop metaphor could be meaningless to you.
2. Metaphors are contextual. Be aware of the context in which the metaphor is used. What can work in one medium or domain may not work elsewhere. Unless you are deliberately juxtaposing for effect, metaphors within a product should fit the context in which they will be used. The subject matter of most projects will likely be rich with its own metaphors. Finding and utilizing them can make powerful connections between the product and its context of use.
3. Fit the metaphor to the functionality, not the other way around. Metaphor should be a tool to help users comprehend unfamiliar content or functionality. So when using a metaphor within a product, start with the new, unfamiliar (to users) material you have and make that the subject of the metaphor, not the referrer. Awkward situations are more likely to happen when functionality is shoehorned into a metaphor. In the best case, metaphors should support concepts, not be supported by concepts or be the concept.
4. Use metaphor to uncover otherwise hidden aspects of the material. While "banking is a game" might be an inappropriate metaphor when used inside a product, it could be a powerful metaphor to use during concept development to show what banking is not. And even perhaps what it is.
5. Discard process metaphors when necessary. Metaphors that have been used in brainstorming or during the design process can grow constrained or simply be inappropriate for users. In some cases, it is better to have no metaphor at all than an inappropriate one.
6. Do not let your metaphor ruin key features. Designers need to realize that all metaphors can obscure as much as they illuminate, and they should choose their metaphors so they do not obscure or distort key features. Microsoft╒s recycling bin in Windows OS is cute, but is less clear than a trash can or a dumpster would be.
7. Choose metaphors that are appropriately scalable. The desktop metaphor has lasted as long as it has because it scales very well. Many varied tasks fit well into its framework; likewise, the folder metaphor. Other metaphoric choices (an envelope instead of a folder, say) may not have scaled so well. (On the other hand, using the metaphor of a workbench instead of a desktop might have supported many activities, not just working with paper.)
8. Let your metaphors degrade and die. Once an appropriate metaphor is understood, it becomes nearly unconscious ("dead"), only to become apparent again with effort. Although this has been criticized, this is a good thing, as intermediate and advanced users should not have to bother with the metaphor and deal more directly with the underlying material. It is only inappropriate metaphors that continue to hinder more experienced users. This is, in fact, a good test for whether or not a metaphor is appropriate. Metaphors can be a double-edged sword.

The rest of this chapter are my own guidelines for metaphor design.

1. Create Specific Metaphors

   To give the widest possible overview, the previous list organizes metaphors into very broad categories. In practice, metaphors for each specific project are much narrower. In deciding to make an enchanted object, for example, designers pick a specific magic item to emulate (say, a magic mirror). Then, the rest of the design process can move from the first principle that "in video conferencing the computer screen is a kind of magic mirror."

   Design decisions flow from this more narrow metaphor, but the broader metaphor provides guidance for how that specific experience fits into a larger set of ideas. If computers are invisible, for example, how do people know where they are? Are they just invisible to people, or also to each other? How does someone tell this specific information processing-enabled invisible experience apart from all the others? How do they know where one invisible computer ends and the others begin?

2. Good metaphors describe function, not appearance

   
   Metaphors should describe deep functional similarities, not superficial resemblance. A well-chosen metaphor maps many of the experiential qualities of one kind of interaction to another. Magic wands in myth, for example, are swung around and pointed at objects to activate actions. The Nintendo Wii captures these qualities well, creating a relatively clear relationship between familiar stories and a new game controller. A game controller that looked like a traditional magic wand (glittery star on top, etc.) but operated like an ink pen would be simply confusing.

3. Metaphors Imply People

   
   

   When we propose that a computer be presented as a metaphorical office or typewriter, one of the things we are really describing is the intended user of this computer, describing him or her as an office worker or typist.

   
   - Blackwell (2006)

   Metaphors establish not only ideas about the meaning of physical affordances and potential ways to use them, but also about the people involved. A metaphor communicates a set of roles for people involved in the device's use. For example, a digital device resembling a stethoscope implies that the user is similar to a medical clinician and that its intended use is diagnostic. If the device is not medical (i.e., rapid transit personnel use it to verify passengers' RFID passes), the mismatch can produce awkward misunderstandings. The transit workers may feel misrepresented by the device, and the passengers may worry about what exactly it is scanning.

   Schank and Abelson (1977) theorized that people reason about the world using expected sequences of actions akin to film scripts. Metaphors embody those scripts by affecting the design of an object╒s form and functionality. By linking the new to the familiar, metaphors communicate how people and devices should act together. Devices are props to carry out those scripts. (Yet another metaphor!) The more explicitly devices rely on metaphor, the more explicitly they reference known characters and how they behave. If the script referenced by the prop does not fit the needs of the people actually using it, or is unfamiliar to them, the prop will be less successful. Thus, the choice of the metaphor should start with the expectations, needs, desires, and actions of the people involved.

4. Use metaphors to inspire, not constrain

   
   

   Almost any metaphor, even an arbitrary one, can trigger new ways of thinking about a product or new solutions to a design problem.

   
   - Saffer (2005)

   In the 1920s, surrealist artists invented a game of map misdirection. Using a map of one city, they would try to navigate another city. They would pick a destination, and simply follow the map. For example, a trip in Berlin using a map of Paris would end at a barber shop in the suburbs instead of the Eiffel Tower. In the process, apart from having some absurdist fun, they would learn more about both Berlin and Paris.

   Similarly, generating new ideas is one of the most powerful results of using metaphor to design user experiences. When mapping one idea to another, the differences between the two domains highlight aspects of both that might not otherwise be noticed. A "butler" device that can understand some spoken comments, for example, probably reaches the limits of its actual understanding very quickly. The designer may well imagine what an actual butler would do in a similar situation. The metaphor raises the question: How do people communicate when they do not understand a phrase, even if they understand each individual word? It also points to a new domain of functionality: more than speech recognition, the system might need to be presented more like a student with limited knowledge of a foreign language than a smoothly polite butler. Similarly, the system may need to imitate how people pause to think in a conversation as a way to explain pauses for processing.

5. Use metaphors to explain, not hide

   
   Metaphors can help explain the functionality of unfamiliar technologies and inspire reflection on how relationships between people and interactive systems unfold. They are, by definition, a distortion of the capabilities and functionality of the technology they are used to explain. If not approached carefully, that distortion can hide vital aspects of the technology from users. The right level of concealment is highly context-dependent, as Saffer's guidelines point out. On one end of the spectrum, toys designed to stimulate the imagination of children can fully embrace the magical metaphor. Misalignments between what children believe is happening and the toys actual functioning are tolerable if they support open-ended, imaginative play. At the other end, airplane cockpit designers must confirm that any metaphorical relationship helps pilots respond correctly to changing conditions and is more cognitively efficient than a non-metaphorical design. Thus, interfaces that simulate hydraulic flaps but control a mechanism that is not actually hydraulic12 need careful evaluation to make sure that they really assist pilots.

Ultimately, metaphors may be most useful during first encounters with a new technology. Declaring that a new technology resembles a familiar one, even if that apparent resemblance is only skin-deep, may lower anxiety and help people transfer existing skills to a new tool. In the transition to a new tool, a few conceptual misunderstandings, or inefficient use, may be a small price to pay for reducing a normal reluctance to try something new. However, as the technology becomes familiar, the metaphor may lose its value. Eventually, the metaphor that seemed so helpful may start creating more problems than it solves. Where this point lies is unique to every product and every group of new users. Recognizing that metaphors have failed can be humbling, but metaphors, like all tools, need regular maintenance.

Tomorrow: Chapter 3, Part 4: Too Much Metaphor, Magic Cap