Models and principles relevant to design

THE WAY I SEE ITCompliance and tolerance

Authors:
Donald Norman

We are failing.

Are products getting more or less usable? Every year products
do get better; every year shows a growth in good design. But the
number of new productsand most important of all, new
product categoriesgrows even faster. We preach the virtues
of good design to the converted, so most of the time our messages
fall on deaf ears. Actually, when it comes to the ever-increasing
number of new product categories, our messages don’t even reach
any ears.

That there is a fundamental mismatch between people and
machines is well recognized within the human-centered design
discipline. This gives rise to many of our cherished principles
about the need for explanation, explicit communication, etc. Such
principles are designed to let people know precisely what is
expected of them so they might behave appropriately. I call this
the “communicative” strategy.

I believe if a communication failure is widespread, the
problem must be in the message. Let me suggest a new approach,
one that tries to give the engineers, programmers, and the
non-hip design community a different way to think about the
issues. The communicative strategy has failed, so let’s try
anew.

The problem with the communicative approach is that it puts
the battle between people and technology into technology’s
territory. All good debaters and negotiators know that you must
control the turf: You have to get the discussion on your own
territory, where the terms and frames of reference are in your
favor. We have to move away from the technological imperatives
and move back to the needs of peopleto put the onus on the
technology to follow human imperatives, constraints, and
behavior.

There are excellent examples we can use to show off the
virtues of good design. Consider how the best voice-technology
systems work today. Suppose the system has been interacting with
a customer over a possible airplane flight and now wishes to know
if it should make the reservation. It asks, “Would you like me to
reserve this flight for you?” In theory, all the person has to do
is say yes or no.

In the early days of voice recognition, some effort was made
to train people to respond “properly,” because anything else
confused the system. This was forcing human behavior onto
technology’s territory. This approach failed.

People have a wide variety of ways of expressing either
response. We can say yes by uttering uh-huh, sure, OK, yes, um,
yeah, or, “cough...wait…um… that’s
fine.” And we can express no by uttering no, no way, sorry,
uh-uh. Moreover, people could very well say other things, such as
what, not now, later, which flight was that, make it a later
flight… etc. Or imagine someone saying “Oh, I don’t know,
maybe, um, well sure. Yes. Do it.” A simple word-spotting program
is apt to hear the “know” and think the person said “no.”

Today good systems accept all of these utterances (and many
more). Moreover, even if the system can’t understand the
response, it does not blame the person; it asks for assistance in
understanding. So with that last complex utterance, it might ask:
“I believe you said yes; is this correct?” These systems do not
ask people to accommodate the technology; they ask the technology
to accommodate people.

The systems follow several principles. One is to constrain the
task domain so much that only a few responses are likely, and the
system can interpret all of them. This is the kind of flexibility
I call compliant and tolerant. Another is to try to infer the
customer’s intention, and to try to satisfy the intention,
regardless of the words spoken. This is effective when it works,
but it can be dangerouswhen it’s wrong, it can be very
wrong. But where the task is well understood and constrained, all
of these approaches work extremely well.

Unfortunately, many of our systems today are rigid and
unbending. I still find it surprising how little understanding
there is of this issue among engineers and programmers. The point
is simple: Stop trying to argue that we need systems that are
usable. The problem with this argument is that nobody
deliberately tries to make systems that are not usable, so they
don’t think they have to do anything differently. After all, they
can use their own systems, right? Instead, let’s argue for doing
something different, something the designers might not normally
think of: making systems compliant, bestowing systems with
tolerance.

Biological systems are compliant. They yield naturally to
forces. Move a hand over a doorknob and the palm and fingers
naturally adjust to the size, shape, and location and then exert
precisely the proper amount of force and torque to hold and turn
the knob. Biology naturally adapts. Technological systems have to
be designed with high precision: They do not have much tolerance
for mismatches in specifications. But peopleand all
biological systemsdo not need this ultra-high precision.
They adjust naturally to the environment, producing highly
robust, reliable, fault-tolerant operation.

Because of this fundamental mismatch, because people cannot
naturally produce actions with the great precision required of
mechanical systems, we have invented a wide range of devices to
help manage the mismatch in sizes and fits. For example, consider
shims, moldings, faceplates and cover plates, slotted screw
holes, and turnbuckles. In some cases, brute force is used: In
automobile factories, workers still use mallets to hammer pieces
into alignment. All of these are ways of either covering up
discrepancies in fit or of adjusting after the fact to make
things fit.

Note that compliance and tolerance are fundamentally related.
Compliance is a way of overcoming rigid requirements of
tolerance. Cover plates are a way of hiding errors. Others are a
way of making adjustments after the fact to make up for the
mismatches that invariably result. I find it interesting that
there are no analogies of shims, cover-ups, or adjustable parts
in nature. Biological systems are flexible, growing systems,
naturally compliant, naturally adjusting themselves to work
together. No rigid mechanical specifications there.

With the advent of computers and embedded processors in almost
every device imaginable, the problems have escalated. Now, not
only must we meet rigid mechanical specifications, but we must
meet strict logical ones as well. We need to conform to the
procedures of the machine, providing it the information it needs
when it wants it, in the format it requires.

Here is where the request for compliance and tolerance helps.
Instead of complaining about unnecessary rigidity in
specifications and requirements, let us ask instead for compliant
systemssystems that comply with normal human behavior.

There are good examples already, ones to which we can point
and use as baselines for developers. First, let me describe the
traditional, noncompliant, intolerant method. Then I’ll describe
a system that does the same task with great compliance, great
tolerance. Gracefully.

Here is the intolerant example. Just recently I tried to sign
up for a lecture series and was asked for my phone number
(“including area code,” it prompted me). Well, that’s reasonable:
Maybe they would call me if the lecture were cancelled? So I
typed my number.

Now, telephone numbers are another abomination imposed upon us
by the rigid requirements of machines. Ten digits is more than
the normal short-term memory span of a busy, multitasking person
can hold, so to make numbers manageable, we have evolved
conventions for breaking the string into shorter, more meaningful
groupings. To do this, we use punctuationspaces,
parentheses, periods, dashes, or commasto separate the
groups. In the United States, we tend to group a phone number
into units of 3, 3, and 4, sometimes with parentheses around the
first three digits. (I ignore the complications caused by the
optional prefixes of “1,” “+1,” because it would make the
following text longer. Note, however, that discussing them would
make my argument even stronger.)

Punctuation marks are not part of the telephone number: They
are there only to make it easier for us to perceive and remember
them. They don’t cause us any problem. When we dial a number
manually, we simply enter the digits and skip over the rest. A
compliant, human-tolerant machine should be just as flexible as a
person: All it has to do is accept the digits and ignore the
non-digits. (And look to see if the first characters are “1” or
“+1” and then either keep, delete, or add them to strings that
don’t have them.)

But no, many systems are built without compliance, without any
tolerance. They want the number their way only. So when I typed
in the number as shown in Figure 1, I was
scolded, as shown in Figure 2: “The form you
submitted contains errors.”

(To maintain my privacy, I am showing the telephone number for
directory assistance for Northern Chicago suburbs. It’s a
perfectly legitimate number, and just to make sure, I tested
it.)

I reviewed the number once more; it looked good to me. I got
no hint as to the nature of the problem, simply a note that my
entry was unacceptable. Some systems at least show what format a
proper phone number should have, but not this one.

Similar problems exist in many different venues. Credit card
numbers are printed in a friendly format on the card; the long
digit string is divided into convenient shorter groups. But most
computers won’t let the number be typed in that way: It must be
typed as one long string, which is therefore highly likely to
contain errors, yet very difficult to proofread.

In the RISKS Digest, the mailing list for professionals
interested in the problems caused by technology, one set of
mailings described a security system with the “challenge”
question: “What is your zodiac sign?” If you happened to be born
under the sign of Leo, you are excluded, because for security
reasons, “your answer to question 1 must be at least 4 characters
in length.” Actually, the length restriction applied to all their
questions, which means your favorite color could not be red, your
dog’s name could not be Sam, your favorite TV show could not be
“24,” “ER,” or “CSI,” etc. Similarly, other security systems ask
for the name of the city in which you were born, but allow city
names to be only one word long. So if you were born in New York
or San Diego, you’re out of luck.

What’s going on here? Lack of compliance, lack of tolerance.
If compliance had been a design specification, perhaps we
wouldn’t have these instances. So now let me turn to a positive
example: how Microsoft does things right.

Compliance Done Properly

Microsoft Office Outlook has done a brilliant job of handling
telephone numbers, dates, times, and addresses. That’s
surprising, since this is a product that people usually target
with complaints, but I intend to heap praise upon it. When
Outlook’s address book or contact forms ask for a telephone
number, they accept any format the person wishes to use, figures
out the proper country, and reformats it accordingly. Start a
phone number with +358, and Outlook knows that you are typing a
Finnish number, so it doesn’t try to format it the way it would a
U.S. number. If it is an American number, you can use almost any
spacing character you wish, as long as the number has the usual
seven, 10, or 11 digits. As a result, you can type in any of
these American phone numbers:

5551212

555.1212

847 555-1212

(847) 555-1212

847.555.1212

8475551212

+18475551212

All of them are transformed into either 555-1212, (847)
5551212, or in the last case, +1 (847) 555-1212.

Most systems are just as bad with dates as they are with phone
numbers. We say dates in all sorts of ways. Most systems scold us
if we don’t do it just the way they like, again, often not even
telling us what they like.

Here are some of the ways in which people write “January 20,
2009”:

1/20/09

1/20/2009

20/1/2009

20 Jan 09

2009.01.20

20th January 09

Hurrah for Outlook! It shows huge compliance, huge tolerance
for our variability. It takes all of these formats and transforms
them into the target specification it prefers: Tue 1/20/2009. But
even better, the target specification is set by the person using
the computer and is stored within the operating system, so all
programs can use the same formats. The settings allow
specification for language, keyboard, country/region, date, time,
and number and measurements, which means, for example, that you
can instruct the machine that 1/9 is 1 September. Yes, this is
old news and is a practice now uniformly followed in the world of
computer operating systems, but the same is not yet true for all
devices and systems.

Outlook goes even further in its tolerance for input forms: It
allows some use of natural language. Type “today” or “the day
after tomorrow,” and Outlook produces the proper date. Times can
be entered in almost any form as long as it can be interpreted:
Type 3 PM, 3 P, 3p, 3pm, or 15, and you get 3 PM. In fact, just a
number works, such as “8,” even though that would normally be
ambiguous, indicating either a.m. or p.m. But Outlook uses
context. If a starting time of 9 a.m. is selected, then typing
“8” for the end time yields 8 p.m. But if the starting time were
7 a.m., the 8 would be interpreted as meaning 8 a.m. In Outlook’s
calendar, typing “now” for the date yields today’s date, while
typing “now” for the time yields the current time.

Intentions

Perhaps the most compliant systems in daily use are search
engines. Because they have so many daily users, they can try to
infer intentions, suggesting alternative spellings or phrases.
These can be quite effective for a number of reasons. First, they
are offered in a nonintrusive, optional manner. The person can
ignore them. Second, most search engines do the search as
specified in addition to making suggestions, so if the suggestion
is wrong, no harm is done. Third, they are often effective
because they are based upon literally millions of other inputs to
the system. I am often surprised by how many legitimate responses
I get when I make a typing error and specify my search
improperly. This means two things. One is that many of the site
creators made similar mistakes in their postings, which allows me
to find them. But second, and better yet, many sites keep track
of common typos and other search errors and add these terms to
their sites so they can be found anyway. Thus, Jakob Nielsen is
careful to make sure that his website can be found even if Jakob
is spelled with a “c” and Nielsen with an “o.”

Here, the compliance and accommodation is provided by the
target as well as by the system. (Google, Live Search, and Yahoo!
all get to the correct targets when asked to find “jacob
nielson,” and all suggest the use of “Nielsen.” None suggest
using “Jakob.”)

Although I praised Microsoft Outlook, I think it’s fair to
condemn Microsoft Word for its failed attempt to determine a
person’s intentions. Many of us have learned the workaround for
Word: When changing the formatting of a sentence, request the
change and then do a control-z (or on a Mac, an apple-z). That
is, Word seems to assume that any format change should apply to
the entire document, so it adds a second, invisible command after
the initiated one. It is therefore necessary to undo that added
command. In the writing of this document, I have spent 30 minutes
undoing formatting changes that seem to appear, willy-nilly, out
of nowhere. Yes, if a person’s intention could be divined, we
could devise truly effective, compliant systems. But this is a
dangerous path. People seldom know their own intentions, so how
can a machine discover them? Microsoft Word stands as the
pinnacle of failure, angering and frustrating its many users
because of its insistence on automatic operations.

We want systems to be on human turf. How do we convey this to
the engineer and programmer communities?

That is the battle we fight. Engineers and programmers, even
intelligent, well-meaning ones, have grown up taking the
machine’s point of view. But these people are experts at the
inner workings of technology. These are not the ordinary people
for whom we design our systems. Nonetheless, because of their
skills, they dominate the technological community. These are the
people we need to convince.

I recommend changing the battleground. Bring it back to human
terms: Ask for compliance and tolerance. Those are new concepts
for designers, but as concepts go, they’re easy to understand.
Ask our engineers, programmers, and fellow designers to aim for
compliant systems, tolerant systems.

As it stands, we must accommodate technology. It is time to
transform the technology to accommodate us.

Disclaimer: Norman has been a consultant to the Microsoft
Office team, but as far as he can tell, none of his suggestions
ever made it to product. He had nothing to do with the virtues he
praises in this article.

Author

Don Norman wears many hats, including cofounder of the Nielsen
Norman group, professor at both Northwestern University and KAIST
(South Korea), and author. His last book was The Design of
Future Things, and the next book? Well, who knows, but this
essay will be in it. He lives at jnd.org.

Permission to make digital or hard copies of all or part of
this work for personal or classroom use is granted without fee
provided that copies are not made or distributed for profit or
commercial advantage and that copies bear this notice and the
full citation on the first page. To copy otherwise, to republish,
to post on servers or to redistribute to lists, requires prior
specific permission and/or a fee.