jnd.org

ORIGINALLY PUBLISHED AS BRINGING DESIGN TO SOFTWARE¹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 5 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 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 de-emphasized, 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 problem 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, let me 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 matters 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. Some customers, unaware that a Macintosh diskette is ejected automatically, under program control, would push the button thinking it would eject the floppy, only to discover that they had turned off their machine, possibly losing their work.

(The power switch on the Macintosh Quadra 601, the PowerMac 6100 and the Performa 6100 was a button underneath the slot for the floppy disk. Some customers, unaware that a Macintosh diskette is ejected automatically, under program control, would push the button thinking it would eject the floppy, only to discover that they had turned off their machine, possibly losing their work.)

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 if 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, 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 are concerned — that is, the people who do the work — 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 builds the least expensive line of machines. Entry Systems staff were cost conscious, for theirs is 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 so much 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, 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 two which 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 are 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 had 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 for whatever product division they were involved with. 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, reach agreement, and 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 with roughly 30 people from several divisions of the company, we were still working on a solution.

First, there was that incredible variety of machine: 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 are placed on the desk, often with the monitor on top. Some are placed on the floor. Some are rotated to stand on their side. Some would seem to require clearly marked, easily accessible switches. Some need 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. So if we wanted a uniform policy for all machines, it had to be one acceptable to the most cost-conscious product–fifty cents added cost could be prohibitive.

Other solutions were ruled out by data from our customer-service centers, treated seriously in the user-oriented culture at Apple. Non technical 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–Windows 95 has adopted the Macintosh design — see footnote). 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.

A safe shutdown. The shutdown procedure designed for the original Macintosh is initiated by a menu action by the user. Each application provides a procedure for cleaning up properly before exiting, so the system can put the system into an appropriate state before shutting down the power under program control. This design was later adopted by other operating systems, such as the 1995 version of Windows.

A switch on the keyboard, the “keyboard power key,” was used only to turn the computer on. 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 television 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 television 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 (i.e., they physically break the circuit from the power mains as the latter enter the devices). 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 menu labeled Special in the Finder). On certain machines, we were experimenting with adding a shut down 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 shut down as readily available and visible as possible.

Occasionally it is necessary to fully disconnect power, such as when you are installing parts, or moving the machine from one place to another. Some 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 some 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 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 it was off, and to initiate a shutdown dialog when the machine was 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 would 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 for both the normal shutdown situation and also 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: How to label the key. You would not believe how much time we spent on the problem of appropriately labeling the keyboard power key. In our current models, the keyboard power-on keys are labeled with a left-facing triangle.

Power key labels. Standards organizations have mandated specific symbols for power keys that reflect what they will do when used. The left-facing triangle on the Macintosh keyboard was selected precisely because it did not have a standard meaning.

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 the symbol was reserved for hard power switches. The triangle has no meaning, so it didn’t 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 vertical bar inside a broken circle (toggled soft-power), but the European standards committee is very strict. There are safety risks associated with thinking a shutdown switch removes all power from the machine when it doesn’t.)

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. Yes, people turn off the power thinking that they are pushing the diskette-eject button. Macs do not have a diskette eject button–they eject disks under program control (except, of course, when the program control fails–but that is another story).

So 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. Emergency shutdown should be done by the user 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 also 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 have considered these problems. I am not happy with the solution that we have reached, but given the technical and business constraints we faced, I can think of no better answer. Sure, those constraints are a bit arbitrary; they have been around for a decade and are thoroughly entrenched.

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 that 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 possibility of removing the keyboard power key or moving away from soft power was 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. To change the culture of the keyboard power key and the shut down menu, is very difficult. In fact, it wasn’t even considered until very late in the power switch deliberations, not because we knew it was difficult, but because it was so embedded in our culture that we didn’t even realize that eliminating the shut-down menu or the keyboard power key was an option.

Apple Computer culture emphasizes ease of use to the extreme. It 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, since it leads to incompatibility as seen by the users.

Moreover, because of the corporate organizational structure, there is no single design center, so that 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. Each method might indeed be optimum for that individual product and its particular design constraints, but the differences across products is sub-optimal for the company. The many different power switch options produced confusion for users. It 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 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 produce three different types of Macintoshes? Why is industrial design centralized whereas human interface is not? Why is industrial design separate from human interface? Why is industrial design high in status, human interface groups low (although the concept is regarded highly–a core competency after all)? And why is 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 a different chapter to cover, but 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 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 announcement, but 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 of 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 change the power management circuits, or eliminate or greatly modify the shut-down menu. Cultures are easier to change during periods of galactic upset. On the other hand, is the power switch really worth all this effort and work?

There is no easy solution–no way to prevent problems like this 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 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 can only be found by posing the right question.

Footnotes1. Norman, D. A. (1996). In T. Winograd (Ed.), Bringing Design to Software. Reading, MA: Addison-Wesley. pp. 233-247. 2. Footnote added in 2001: Windows machines now all face the same problem discussed in this paper. Now, all Macintoshes and Window machines alike must be powered down from menu control: disconnecting power (whether by pulling the plug or by using the on/off switch, is dangerous for all computers, and usually when you start up again afterwards, you will be scolded (which is a real pain, because usually it wasn’t your fault – it was the only way to stop the system.). Most machines now incorporate the power switch override: if all else fails, depress or hold-down the power switch until the machine turns off (usually this takes for 5 to 15 seconds).