Donald A. Norman
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.
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, as shown in Figure 14.1. 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.
>>>>>>INSERT FIGURE 14.1 ABOUT
HERE<<<<<<
Figure 14.1 A misleading power switch,. 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!
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?
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). 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 14.2 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, as in Figure 14.3.
>>>>>>INSERT FIGURE 14.3 ABOUT
HERE<<<<<<
Figure 14.3 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.
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,
as illustrated in Figure 12.4, 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.
>>>>>>INSERT FIGURE 14.4 ABOUT
HERE<<<<<<
Figure 14.4 Uncoordinated solutions,. The power switches on these
different Macintosh models grew out of constraints that were given
priority by different design organizations, and show a wide variety
of solutions, rather than offering a consistent design language that
can be learned and understood by users.
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.
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.