12

Design as Practiced

Donald Norman

When you are asked to solve a problem, look beyond it. Ask why that particular problem arose in the first place. Search beyond the technical: Question the business model, the organizational structure, and the culture. The path to a solution seldom lies in the question as posed: the path appears only when we are able to pose the right question.

Donald Norman is one of the founders and professional leaders of the discipline of cognitive science, and of its predecessor field, cognitive psychology. He is well known for his pioneering experiments on phenomena of memory and attention in humans, and he created one of the first departments of cognitive science, at the University of California, San Diego.

Norman was not satisfied, however, with the rules of the game in academia. As he said in one of his recent books, Things that Make Us Smart (1993, p. xii), “University-based research can be clever, profound, and deep, but surprisingly often it has little or no impact either upon scientific knowledge or upon society at large. What matters is precision, rigor, and reproducibility, even if the result bears little relevance to the phenomena under study.” Over the years, Norman moved away from the rigorous irrelevance of the academic journals, shifting his attention to the things that we encounter every day in our lives—the doors, faucets, and computers—and to complex systems, such as airline cockpits and nuclear power plants (see Profile 14). For each of these objects, design succeeds or fails, depending on how well it works for people.

At Apple Computer, Norman is now Vice President for Advanced Technology, heading Apple’s research program. When he first arrived at Apple as an Apple Fellow, Norman established a small, high-level group, called the User Experience Architect's Office, which worked across the company to make Apple products easier to use. A key goal in instituting this office was to get user-experience professionals involved at product conception, and to have them be part of the design team throughout the development process. Norman chose the phrase user experience to emphasize that his office's concern was not just the interface. It was more than menus and icons; it was everything related to the user's experience of the product.

In this chapter, Norman reflects on his experience in trying to accomplish his goals at Apple. He tells the story of the Macintosh power switch: of how he tried to simplify its placement and function, but was thwarted on all sides by sensible, reasonable technical problems. His central point is that design as practiced is very different from design as taught. In the actual situation, cultural, social, and organizational issues can dominate the user-oriented aspects of design.

—Terry Winograd

§ § §

Author's acknowledgment: My thanks to Sue Bartalo, who co-led the power-switch committee, and struggled through all the issues and draft reports, and to Laura De Young and Julie Norman for valuable editorial comments.

Design as practiced is considerably different from design as idealized in academic discussions of "good design." A few years ago, I made the transition from the university to industry—a deliberate decision on my part to practice what I had long been preaching, and to try to understand the constraints and pressures from the business point of view. How nice it would be, I thought, to be able to see products in the marketplace that reflected my design philosophy. This chapter recounts one stage of my learning process: Issues that seem simple from the vantage point of academia are often extremely complex when seen from inside the industry. Indeed, the two sides seem hardly to be speaking the same language. In the course of my experiences, I have come to recognize that industry faces numerous problems that are outside of the scope of the traditional analyses of design. In particular, there are management and organizational issues, business concerns, and even corporate culture.

Management and organizational issues reflect that humans work well in small groups of five to 10 individuals, and work less well as the group size increases. As a result, over the past few millennia, various organizational structures have arisen to allow people by the hundreds, thousands, hundreds of thousands, and even millions (in the case of armies) to work effectively. Each organizational solution, however, has its tradeoffs, emphasizing one aspect of control to the detriment of others. University laboratories, with their emphasis on small, innovative groups, where individual work is highly rated and group activities often are deemphasized, do not face these pressures.

Business concerns deal with profit and loss. Innovative products do not necessarily succeed in the marketplace, and no company can afford to bring out unsuccessful products. The list of companies with the correct product at the wrong time is long, and their names long forgotten. Had you bought stock in the first American manufacturers of automobiles, typewriters, or personal computers, you would have lost your money. Even successful companies have difficulty in making the transition to a new product generation: Tell your customers that you have an entirely new and superior approach, and they will stop buying the old, but will postpone buying the new until it is “proven,” by which time you are apt to be bankrupt. The problems of maintaining the installed base, and what have been come to be known as legacy systems, can throttle an otherwise innovative industry.

Cultural issues are perhaps the hardest to identify and deal with. Once people are acculturated, their thoughts, beliefs, and actions are biased, without their conscious awareness. Of all the problems that beset the design industry, cultural issues are probably the most insidious.

The Problem of the Macintosh Power Switch

To illustrate the depth of the design problem, I will tell you the story of the Macintosh power switch—of how a dedicated committee tried to simplify the placement and function of the switch, but succeeded only through multiple compromises in the face of many reasonable technical problems. The power switch is a relatively trivial matter, and that is why it is such a good example. Even the most trivial problems are constrained by so many issues that their solution becomes complex or even impossible.

Apple produces numerous models of its Macintosh computer. They all run the same basic software, with technical modifications in the underlying drivers and core operating system to reflect different hardware structure. All current Macintosh computers come with a number of standard physical controls and connectors. A good deal of attention has gone into the development of a consistent design language for hardware features (see the discussion by Rheinfrank and Evenson in Chapter 4). In this context, the lack of standardization of the power switch seems bizarre. Some machines have it in the front, others on the back. Some have toggle switches, others have pushbuttons. Some machines do not appear to have any power switch at all. Users continually have trouble finding the switches.

The design that finally called for remedial action was the one in which the power switch was a button underneath the slot for the floppy disk, as shown in Figure 14.1. Some customers, unaware that a Macintosh floppy disk is ejected automatically under program control (and a few who were not paying attention), would push the button, expecting it to eject the floppy, only to discover that they had turned off their machine, possibly losing their work.

>>>>>>INSERT FIGURE 14.1 ABOUT HERE<<<<<<

Figure 12.1 A Misleading Power Switch The power switch on the Macintosh 610 (and later related models) is a button underneath the slot for the floppy disk. Users confused it with the disk-eject button that is located similarly on other brands of computers, leading them to shut off the Macintosh's power accidentally. (Source: Courtesy of Apple Computer.)

Eventually, a customer complaint to one of the Internet's news groups got bounced around the internal networks at Apple. The director of the industrial-design department and I contacted the vice-president who supervised three of the divisions that produced Macintoshes. We all agreed that the problem was detrimental to our customers and completely unnecessary. We were asked to devise a solution, and were assured that it would be followed. “Aha,” I said to myself, “the power switch can be a test case of my desire to restructure the design process at Apple. I don't care much about power switches, but perhaps this case will not only solve the power-switch problem but also make a small improvement in usability—one that is easy to implement and that would indeed make a difference.” Was I mistaken!

Design in a Large Organization

Remember, people work well in small groups, so as soon as the size of the organization gets large, communication problems arise. Organizations are in a continual struggle against this problem, with repeated attempts to “reorganize,” as though there were a perfect structure that would somehow solve all difficulties. There isn’t. So the story as told here reflects the organization that existed then—not the one that exists now. Then, I was an Apple Fellow; now, I am a vice-president. Does that make any difference? No, not really. Then, the hardware and software divisions were separated; now, they are merged. Does that make a difference? Yes, a little. Today, there is more cohesion in the organizational structure, but, as a result, there are larger organizations, which pose their own communication difficulties. Does that really make a difference? No, because although the top of the organization has been restructured, as far as the lowest-level engineers—that is, the people who do the work—are concerned, nothing has changed except the names of the bosses of their boss’s boss.

The first problem was to discover who was in charge. Answer: No one. Apple did not have a single design center. Design was done across the company. Moreover, the Macintosh was produced by four different divisions of the company: Macintosh Entry Systems, Desktop Systems, Portables, and Apple Business Systems.

Entry Systems built the least expensive line of machines. Entry Systems staff were cost conscious, for they were in an incredibly competitive marketplace, where a few dollars in selling price makes a difference. Desktop Systems was responsible for the high-end machines, where cost is still important, but not nearly as much so as for the entry-level machines. For Portables, weight, size, and power consumption dominate the design issues. Size limitations meant that there was no physical room to implement some of our proposals. Apple Business Systems produced servers—machines meant to be tucked away somewhere out of sight, and to deliver files, printing, or communication services unattended, with great reliability. In this case, the power switch sometimes has to be hidden, locked, or otherwise protected against accidental use or access by unauthorized people.

In addition to the product-design centers, a number of other groups were involved in design, including the central industrial-design group and the human-interface group, which serviced the software division and all the hardware divisions except for the two that had their own human-interface groups: Business Systems and the Personal Interactive Electronics Division (where the Newton was produced). Several groups were concerned about localization—the process of adjusting designs to the languages, customs, and regulations around the world. In addition, there were safety issues, especially relevant to power switches, and another office dealt with equal access by the handicapped. My own contribution was in the User Experience Architect’s Office, which worked with all Apple divisions.

When I thought that Apple had numerous people qualified to solve this problem, I was correct. The trouble was that each of them chose a different solution, appropriate to their product division. Still, this obstacle did not appear to be insurmountable. All we needed to do, I thought, was to get together all the relevant people in one room to discuss the issues, to reach agreement, and to write a draft report. The draft would be circulated and discussed, and then perhaps a second meeting would resolve any disagreements. End of story, right?

The Search for a Solution in a Complex Design Space

We quickly gathered a small team: One person from product design, one from human interface, and one from hardware. Then, we sent notices across all of Apple, soliciting interested parties. We gathered names of about 30 people representing a wide variety of interests and groups, appearing to cover all relevant constituencies.

The committee was extremely cooperative and constructive. Everyone agreed that the current problems with the power switch where unwarranted and ought to be solved. Everyone shared numerous concerns and issues. But each person also came with a set of constraints dictated by the concerns of a particular organization. Each person explained those constraints in logical, rational form, and, after each explanation, the entire group would nod in sympathy, and say, yes, those are all valid points. Alas, the constraints were mutually incompatible. Three months later, after numerous meetings and roughly 10 draft proposals, and further meetings, we were still working on a solution.

First, there was the incredible variety of machines: from those used as high-power workstations, to servers (which need protected power switches), to office, home, and educational machines, as well as portables. Some machines were placed on the desk, often with the monitor on top. Some were placed on the floor. Some were rotated to stand on their side. Some required clearly marked, easily accessible switches. Some needed switches out of reach.

Several otherwise-simple solutions were ruled out by cost considerations. In the low-end market, where cost dominates, even a slight extra cost can disrupt product sales. If we wanted a uniform policy for all machines, it had to be acceptable to the most cost-conscious product—50 cents of added cost could be prohibitive.

Other solutions were ruled out by data from our customer-service centers, which are treated seriously in the user-oriented culture at Apple. Nontechnical users of computers—the vast majority of our customers—were confused by the existence of the power switch. If they saw one, they used it to turn off the machine—instead of using the shutdown software—with the potential to cause massive software problems.

Other companies put the burden of safety on the users; if users destroy files, it is their fault for failing to use the proper procedure. On a machine running Unix, only the system operator is supposed to turn off the machine, and then only after following a set of procedures, including running a special program (sync) to ensure the integrity of files on the hard disk. On DOS and Windows 3.1 machines, the power is supposed to be turned off only when the machine is in the DOS mode with no open files (Windows 3.1 users must leave Windows first—Windows95 has adopted the Macintosh design). If the user of any operating system turns off the machine while it is running an application, or when files are open, there may be damage to the system or loss of data. Putting the burden on the user to do a task properly goes against the culture of the Macintosh community.

An elegant solution emerged in the early days of Macintosh: Shutdown was done by the computer, rather than by the person. When you were finished working, you evoked the Shut Down procedure from a menu, and let the machine turn itself off in a graceful, safe way, as illustrated in Figure 14.2.

>>>>>>INSERT FIGURE 14.2 ABOUT HERE<<<<<<

Figure 12.2 A Safe Shutdown The shutdown procedure designed for the original Macintosh is initiated by the user via a menu action. Each application provides a procedure for cleaning up properly before exiting, so the system can put itself into an appropriate state before shutting down the power under program control. This design was later adopted by other operating systems, such as Windows95. (Source: Reprinted by permission from Apple Computer. Getting Started with Your Macintosh Quadra 840. p. 21.)

A switch on the keyboard, the keyboard power key, was used only to turn on the computer. Today’s Macintosh models—like many consumer-electronic devices—use soft power control: They never have all power removed. Just as the power button on the TV remote does not cause a hard shutdown of the TV set, neither does the Shut Down menu entry on the Mac. After all, if these selections really shut down all power, the TV remote would not be able to turn the power back on, and the Mac’s keyboard would not turn on the machine. Hard power switches do disconnect full power; they physically break the circuit from the power mains. But these solutions are being phased out and, in any event, lead to severe software problems if they are used at inopportune times.

With soft power control, it is not necessary to have a power switch at all: You can put a switch on the keyboard to turn on the machine, and use menu control to turn off the machine. For this reason, our machines made for the home and school markets took away the power switch and added an extra Shut Down command to the Apple menu that was visible in almost every Macintosh application (in addition to its traditional location in the menu labeled Special in the Finder). On certain machines, we experimented with adding a shutdown dialog with the user, to be triggered whenever the power key on the keyboard was hit. Experience indicated that we should hide the power switch, while making software shutdown as readily available and visible as possible.

Occasionally, it is necessary to disconnect power fully, such as when you are installing parts, or moving the machine from one place to another. Certain safety regulations require that it be possible to disconnect all power. Also, when the operating system crashes, a soft, graceful shutdown under software control is not possible. Here is the beginning of the technical problem: How can you provide for software control of shutdown, yet allow an emergency means of shutting down when the software has failed? The emergency method has to be available when needed, but must be sufficiently inconspicuous that it is not invoked under normal conditions, because then it might do more harm than good.

So, what we wanted was a simple and effective way for people to turn on their machine and to shut down or close safely all files, applications, queues, and caches, and to turn off all power except for that required to monitor essential machine states. But then we had to worry about abnormal situations, where the software was corrupted such that the software-controlled shutdown process would not work. In this case, there had to be some easy way of forcing either a shutdown or a reboot. We also needed to provide a method of putting the machine into an energy-saving, or sleep, state, and of awakening it. Programmers wanted a way of forcing entry into the debug state. And, of course, the scheme had to be protected against accidental initiation.

The proposals therefore were variations of the following:

Use the keyboard power key to power on the machine when the machine is off, and to initiate a shutdown dialog when the machine is on. In addition, provide a means of entering the debug state and of triggering a forced shutdown in case of emergency. Finally, include a real power switch on the main box housing the computer, where it will be inexpensive, not be too easily accessible, but easy to find in an emergency. The functioning of the switch has to be readily understood by people who have never used a Mac before, but must not annoy our skilled, power users. Moreover, the solution has to work both for the normal shut-down situation and when the system software is no longer responding.

The problem was further complicated by the need to satisfy international safety requirements, to work across the world with a variety of languages and cultural expectations, and to be usable by people with a variety of disabilities.

For example, one problem that we encountered was totally unexpected: You would not believe how much time we spent on the problem of labeling the keyboard power key. In our current models, the keyboard power-on keys are labeled with a left-facing triangle. Why? Because that symbol does not mean anything! The symbol used earlier (a vertical line inside a circle) was not permitted because the European standards authorities insisted that it was reserved for hard power switches. The triangle has no meaning, so it does not violate any standards. Few—European or American—are confident about the meaning of the vertical bar and circle (on and off, respectively), let alone a bar inside of circle (a toggled on–off), or a vertical bar inside a broken circle (toggled soft power), but the European standards committee is strict. There are safety risks associated with thinking that a shutdown switch removes all power from the machine when it does not.

So, what seemed to be a simple task—one that would remove all the confusions of our power-switch locations—turned out to be incredibly complex. The final proposal had a soft power key on the keyboard, labeled “on/off,” (translated into whatever was appropriate for the language of the keyboard). The real power switch was on the rear of the CPU box. The user could initiate an emergency shutdown by holding down the power key for greater than 5 seconds, or by depressing the rear power switch twice (the first attempt tries a normal soft shutdown). We recommended a separate reset button, but, in deference to the cost considerations of the entry-level systems and the space considerations for portables, we did not require one. A policy of indicator lights was established, so that a user could tell whether the machine was on, off, or in energy-saving mode.

I hear people saying, “What if someone accidentally hit the power key, or what if a book fell on it, or a cat walked across the keyboard—would you lose all your work? And how would anyone ever discover that holding down the power key for 5 seconds caused a forced shutdown? Doesn’t that violate all sorts of design rules, including ones that you (Don Norman) have been advocating?” Yes, these are valid points. We obviously considered these problems. I am not happy with the solution that we reached, but given the technical and business constraints that we faced, I could think of no better answer.

The Macintosh Culture and Design Constraints

Why were there so many technical problems? Macintosh designers had made early decisions about the appropriate way to simplify tasks for the user, which launched the power-control system along a particular technical path. This path got ever more complex as the variety of computers increased. Meanwhile, part of the culture forced on every computer company with an installed base is the emphasis on backward compatibility: Once a concept is introduced, maintain it.

Our committee started with a number of assumptions, many of them unstated. We took for granted that there would be soft control of power under normal circumstances, that the machine would be started through the power key on the keyboard, and that the hard power switch should be used only under exceptional circumstances. In addition, we wanted to keep the ability for programmers to get to the debug state, and to make possible emergency solutions. The possibilities of removing the keyboard power key or of moving away from soft power were never even discussed.

The cultural values associated with simplicity and compatibility were seldom stated, and some may not even have been conscious. In fact, it was only after all the power-switch meetings were finished that we were able to reflect on the incidents and to realize that many of the so-called technical issues were really a result of the underlying Macintosh culture, and that, if we now went back and changed certain of those cultural assumptions, the technical problems would change. Changing the culture of the keyboard power key and the Shut Down menu item is exceedingly difficult. In fact, we didn't even consider it until late in the power-switch deliberations—not because we knew that it was difficult, but because the assumptions were so embedded in our culture that we didn’t even realize that we had the option.

Apple Computer culture emphasizes ease of use to the extreme. Ease of use is part of the core competency of the corporation. It causes many programmers and engineers to feel empowered to design the user side of the product just as readily as the technical side. That is not necessarily good, when it leads to incompatibility as seen by the users.

Moreover, because of the corporate organizational structure, there is no single design center. Even if a design is put to user test, with human-interface professionals, the solution for a problem for the product produced by one group might differ from the solution to the same problem in a product produced by a different group. The many different power-switch options produced confusion for users because they violated the principle of creating a consistent design language across an entire product line, as discussed by Rheinfrank and Evenson in Chapter 4.

Another problem is organizational. As a result of corporate history, Apple had a particular organizational structure, with separate profit centers, each making one kind of product. This organizational structure was ideal for certain aspects of corporate business, but was inefficient for others. In particular, it did not lend itself to coherent, consistent design decisions. Centralized groups are ideal for that purpose. Centralized groups, on the other hand, tend to lead to bloated bureaucracies, with long decision chains and inefficient and slow processes. These organizational issues end up dictating just how design is done.

Why did Apple have four different divisions (Personal Interactive Electronics, AppleSoft (operating systems), Apple Business Systems, and Apple PC (hardware)? Why were there three different divisions within Apple PC that produced three different types of Macintoshes? Why was industrial design centralized, although human interface was not? Why was industrial design separate from human interface? Why was industrial design high in status, and human interface low (although the concept is regarded highly—a core competency after all)? And why was there no human-interface group in the hardware division? (Answer: Because hardware is thought to be relevant to industrial design—software is where human-interface issues arise. This attitude prevails despite its obvious fallacies, even though the hardware division writes software, such as control panels and drivers.) These issues would require another chapter to cover; they result from historical accident, cultural attitudes, and difficult tradeoffs in the organization of large corporations. In fact, the product-division organization described above was changed after the power-switch committee published its report. As of 1995, all Macintoshes are produced in the same division and some of the problems described in this chapter have gone away. Most still remain.

Epilogue

Just as we were about to call the final meeting and to issue the proclamation, a new problem arose. IBM and Apple Computer, after months of deliberation, determined to issue a new, common hardware platform (CHRP, pronounced “chirp”) for computers powered by the PowerPC chip. IBM and Apple agreed to manufacture machines that all met the CHRP standards, thereby ensuring that machines made by either manufacturer would run the same software. Oops! What about the special circuits that implement the keyboard power key and the emergency shutdown procedures? Would there even be a power key? In fact, would all computers have the Apple Desktop Bus that connects the keyboard and mouse to the CPU, and through which the power key works? Did the new reference standard even discuss the power switch? As of the publication of this book, we still do not know the answers: Some of these details were not decided in the original announcementl; they were left for further committees to resolve. One thing we did learn: the special power-management circuit on which we had counted to monitor the state of the operating system and to control the power operation of the machine would no longer be used. It would be replaced by a new system, as yet not specified.

What will we do? We will schedule more meetings. We will add representatives for the common reference platform to the list of contacts. That may be a blessing in disguise: With the advent of the common reference platform, we have an excuse to change the culture. We could decide to get rid of the keyboard switch, or to change the power-management circuits, or to eliminate or greatly modify the Shut Down menu item. Cultures are easier to change during periods of galactic upset. On the other hand, is the power switch really worth all this effort?

There is no easy solution. There is no way to prevent problems such as this one from arising—no matter how cleverly we redesign the machines or redesign the organization. But the lessons of this story do lead to a positive prescription for design—one that I have long taught my students and have followed myself. When you are asked to solve a problem, look beyond it. Ask why that particular problem arose in the first place. Search beyond the technical: Question the business model, the organizational structure, and the culture. The path to a solution seldom lies in the question as posed: the path appears only when we are able to pose the right question.