Cooper ( Interaction Design Inspiration The Myth of Metaphor Cooper books by Alan Cooper, Chairman & Founder Articles June 1995 Newsletter Originally Published in Visual Basic Programmer's Journal Concept projects Book reviews Software designers often speak of "finding the right metaphor" upon which to base their interface design. They imagine that rendering their user interface in images of familiar objects from the real world will provide a pipeline to automatic learning by their users. So they render their user interface as an office filled with desks, file cabinets, telephones and address books, or as a pad of paper or a street of buildings in the hope of creating a program with breakthrough ease-of- learning. And if you search for that magic metaphor, you will be in august company. Some of the best and brightest designers in the interface world put metaphor selection as one of their first and most important tasks. But by searching for that magic metaphor you will be making one of the biggest mistakes in user interface design. Searching for that guiding metaphor is like searching for the correct steam engine to power your airplane, or searching for a good dinosaur on which to ride to work. I think basing a user interface design on a metaphor is not only unhelpful but can often be quite harmful. The idea that good user interface design is based on metaphors is one of the most insidious of the many myths that permeate the software community. Metaphors offer a tiny boost in learnability to first time users at http://www.cooper.com/articles/art_myth_of_metaphor.htm (1 of 8) [1/16/2002 2:21:34 PM] Cooper ( Interaction Design tremendous cost. The biggest problem is that by representing old technology, metaphors firmly nail our conceptual feet to the ground, forever limiting the power of our software. They have a host of other problems as well, including the simple fact that there aren't enough metaphors to go around, they don't scale well, and the ability of users to recognize them is questionable. Confusing the issue is the problem that most of what we consider metaphoric interface isn't. The three interface paradigms I think that there are three dominant paradigms in software user interfaces. I call these three the technology paradigm, the metaphor paradigm, and the idiomatic paradigm. The technology paradigm is based on understanding how things work, a difficult proposition. The metaphor paradigm is based on intuiting how things work, a problematic method. The idiomatic paradigm is based on learning how to accomplish things, a natural, human process. In general, we have been progressing from technology through metaphor and are just now becoming aware of idiomatic design. Although there is ample evidence of all three in contemporary software, the metaphor paradigm is the only one that has been popularized, so we pay it lots of lip service and, all too often, hamper the creation of really good interfaces by following its false trail. The technology paradigm The technology paradigm of user interface is simple and incredibly widespread in the computer industry. It merely means that the interface is expressed in terms of its construction, of how it was built. In order to successfully use it, the user must understand how the software works. There was a movement in building architecture in the 1960's called Metabolist, and its influence is still evident. In metabolist architecture, the elevator shafts, air conditioning ducts, cable runs, steel beams and other construction impedimenta are left uncovered and readily visible from both inside and out. The muscles, bones and sinews of a building are exposed-even emphasized-without any hint of modesty. The idea being that the building is a machine for living and its form should http://www.cooper.com/articles/art_myth_of_metaphor.htm (2 of 8) [1/16/2002 2:21:34 PM] Cooper ( Interaction Design follow its implementation details. The overwhelming majority of software programs today are metabolist in that they show us without any hint of shame precisely how they are built: One button per function, one function per module of code, commands and processes that precisely echo the internal data structures and algorithms. We can see how a technology program ticks merely by learning how to run it; The problem is that the reverse is also true: We must learn how it ticks in order to run it. Engineers want to know how things work, and the technology paradigm is very satisfying to them, which, of course, is why so much of our software follows it. Engineers prefer to see all of the gears and levers and valves because it allows them to understand what is going on inside the machine. That those artifacts needlessly complicate the interface seems a small price to pay. Although engineers want to understand the inner workings, most users don't and lack the time if they do. They'd much rather be successful than be knowledgeable, a state that is often hard for engineers to understand. The metaphor paradigm In the 1970s, the modern graphical user interface was invented at Xerox Palo Alto Research Center (PARC). It has swept the industry, but what, exactly, is it? The GUI, as defined by PARC consisted of many things: Windows, buttons, mice, icons, metaphors, pulldown menus. Some of these are good and some are not so good, but they have all achieved a kind of holy stature in the industry by association with the empirical superiority of the ensemble. In particular, the idea that metaphors are a firm foundation for user interface design is a very misleading proposition. It's like worshipping 5.25" floppy diskettes because so much good software once came on them. The first commercially successful implementation of the PARC GUI was the Apple Macintosh, with its desktop metaphor, wastebasket metaphor, overlapping sheets of paper metaphor and file folder metaphor. The success of the Mac wasn't because of these metaphors but because it was the first computer that defined a tightly restricted vocabulary for communicating with users based on a very small set of mouse actions. The metaphors were just nice paintings on the walls of a well-designed house. http://www.cooper.com/articles/art_myth_of_metaphor.htm (3 of 8) [1/16/2002 2:21:34 PM] Cooper ( Interaction Design Metaphors don't scale very well. A metaphor that works well for a simple process in a simple program will often fail to work well as that process grows in size or complexity. Icons for files was a good idea when computers had floppies or 10 megabyte hard disks. In the days of gigabyte hard disks and thousands of files, icons can get pretty clumsy. We understand metaphors by intuition. In user interfaces, we grasp the meaning of the metaphoric control because we mentally connect it with some other process or thing we have already invested time and effort into learning. The great strength of this method is its efficiency, taking advantage of the awesome power of the human mind to make inferences, something that CPUs are incapable of. The weakness of this method is that it depends on the creaky, cantankerous, idiosyncratic human mind, that may not have the requisite language, knowledge or inferential power necessary to make the connection. Metaphors are not dependable the way that understanding is. Sometimes the magic works, sometimes it doesn't. The intuition of the metaphor paradigm takes place without understanding the mechanics of the software, so it is a step forward from the technology paradigm, but its power and usefulness has been inflated to unrealistic proportions. Webster defines intuition as "the power or faculty of attaining to direct knowledge or cognition without evident rational thought or inference." Wow! No thinking involved. It is silly to imagine that we can base good user interface design on a kind of mental magic that thumbs its nose at thinking. We intuit things by mentally comparing them with what we have already learned. You instantly intuit how to work a wastebasket icon because you once invested the effort to learn how to work a real wastebasket, preparing your mind to make the connection years later. But you didn't intuit how to use the original wastebasket. It was just extremely easy to learn. Which brings us to the idiomatic paradigm, which is based on the fact that the human mind is an incredibly powerful learning machine, and that learning isn't hard for us. The idiomatic paradigm This third method of user interface design solves the problems of both of the previous two. I call it idiomatic because it is based on the way we learn and use idioms, or figures of speech, like "beat around the http://www.cooper.com/articles/art_myth_of_metaphor.htm (4 of 8) [1/16/2002 2:21:34 PM] Cooper ( Interaction Design bush" or "cool." They are easily understood but not in the same way metaphors are. There is no bush and nobody is beating anything. We understand the idiom because we have learned it and because it is distinctive. Pretty simple, huh? This is where the human mind is really outstanding, mastering learning and remembering idioms very easily without having to depend on comparing them to known situations or understanding how they work. It has to, because most idioms don't have any metaphoric meaning at all. Most of the controls on a GUI interface are idioms. Splitters, winders, comboboxes and scrollbars are things we learn idiomatically rather than intuit metaphorically. We tend to think that learning is hard because of the conditioning we have from the technology paradigm. Those old user interfaces were very hard to learn because you also had to understand how they worked.