Models and principles relevant to design

XVI.3 May + June 2009
Page: 61
Digital Citation

THE WAY I SEE ITCompliance and tolerance

Donald Norman

back to top 

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, " 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.

back to top  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.

back to top  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.

Outlook, bless you. Word, damn you. Suggestion: The design teams should talk with one another.

back to top  Accommodation

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.

back to top  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

back to top  Footnotes


back to top  Figures

F1Figure 1. The website request for a telephone number. The * means the information is required: The digits show the entry of a real, working number.

F2Figure 2. "The form you submitted contains errors." This is the response when a legitimate phone number is entered into the website, but not in the format it wants. The user learns that something is wrong, but not why. The number is valid, but evidently the format is not.

back to top 

©2009 ACM  1072-5220/09/0500  $5.00

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.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2009 ACM, Inc.

Post Comment

No Comments Found