jnd.org

Column written for Interactions. © CACM. This is the author’s version of the work. It is posted here by permission of ACM for your personal use. It may be redistributed for non-commercial use only, provided this paragraph is included. The definitive version was published in Interactions, volume 16, issue 3, pages 61-65_: Norman, D. A. (2009). _

We are failing.

Are products getting more or less usable? Yes. Every year,products do get better: every year shows a growth in good design. But thenumber of new products – and most importantly of all, new product categories,grows even faster. We preach the virtues of good design to the converted, somost of the time our messages fall on deaf ears. Actually, when it comes to theever-increasing number of new product categories, our messages don’t even reachany 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 that they might behave appropriately. I call this the “communicative” strategy.

I believe that 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 have to control the turf: you have to get the discussion on to 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 that we can use to show off the virtues of good design. In this article I’ll provide several positive cases. 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 yes, uh-huh, sure, OK, um, yeah, 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. Or it might ask, 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 to 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 all of these can be interpreted. This is the kind of flexibility I call compliance and tolerant. Another is to try to infer the customer’s intention, and to try to satisfy the intention, regardless of the words. This is effective when it works, but can be dangerous and very mistaken when it errs. But where the task is well understood and constrained, all of these approaches work extremely well.

Unfortunately, many of our systems today are still 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 useable, so they don’t think they have to do anything differently. After all, they can use their own systems? Instead, let’s argue for doing something different, something the designers might not normally think of: making systems compliant, giving systems 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 high high-precision. They adjust themselves 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 doing adjustments 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 tight, rigid mechanical specification, but we must met 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 wants to have.

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 we can point to and use as baselines for developers. Let me give an example. First, let me describe the traditional, non-compliant, intolerant method. But 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 my phone number (“including area code” it prompted me). Well, that’s reasonable: maybe they would call me to say the lecture was cancelled? So I typed my number: 847 555-1212

(To maintain my privacy, for this article instead of using my real phone number, I show the telephone number for directory assistance for area code 847 (Northern Chicago suburbs). It’s a perfectly legitimate number, and just to make sure, I tested it.)

Phone (including area code) *

847 555-1212

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

Now, telephone numbers are another abomination imposed upon us by the rigid requirements of machines. Ten digits is longer than the normal short-term memory span of a busy, multi-tasking person, 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 me, as shown in

Figure 2: “The form you submitted contains errors.”

I looked at the number again: it looked good to me. I was given no hint as to the nature of the problem, simply that it was unacceptable. Some systems at least show what format a proper phone number should have, but not this one.

The form you submitted contains errors. The affected form fields are outlined in red.

The phone number you exhibited appears to be invalid.

Phone (including area code) *

847 555-1212

Figure 2. “The form you submitted contains errors.” The response when a legitimate phone number is entered into the website, but not in the format it wanted. I am told it is wrong, but not why. The number is valid, but evidently the format is not.

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 has to be typed as one long strong 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 systems 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, there are other security systems that ask for the name of the city in which you were born, but only allow city names to be one word. So if you were born in New York or San Diego, you are out of luck.

What is 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: How Microsoft Outlook Does Things Properly

Microsoft Office Outlook has done a brilliant job of handling telephone numbers, dates, times, and addresses. Surprise: this is a product that people usually target with complaints, but I intend to heap praise upon them. When Outlook’s address book or contact forms ask for a telephone number, it accepts any format the person whishes to use, figures out what country it belongs to, and reformats it into a standard form. Start a phone number with +358 and it knows that you are typing a Finnish number, so it doesn’t try to format it the same way it does for US numbers. If it is an American number, you can use almost any spacing character you wish, as long as the number has the usual 7, 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

And they all get transformed into either 555-1212, (847) 555-1212, 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 people write the date 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, number and measurements format 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 not yet in 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 AM or PM. But Outlook uses context. If a starting time of 9 AM is selected, then typing 8 for the end time yields 8 PM, but if the starting time were 7 AM, the 8 would be interpreted as meaning AM: 8 AM. 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 non-intrusive, 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 do 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 mistypings 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 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 map, 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 you could really figure out a person’s intention, 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: you are to be praised. Word, you are to be damned. Suggestion: talk to one another.

Accommodation

We want systems to be on the human turf. How do we get this across to the engineers and programmers communities?

That is the battle we fight: engineers and programmers, even intelligent, well-meaning ones, have grown up from taking the machine’s point of view. But these people are experts at the inner workings of technology. These are not the ordinary people that we design our systems for. 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 concepts that are easy to understand. Ask our engineers, programmers, and fellow designers to aim at compliant systems, tolerant systems.

Technology must accommodate people. Today it is we who must accommodate technology. It is time to transform the technology to accommodate to us.

The author:

Don Norman wears many hats, including co-founder of the Nielsen Norman group, Professor at Northwestern University, and author. His last book was The Design of Future Thing and the next book, well who knows, but this essay will be in it. He lives at jnd.org.

Disclaimer for this article: 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.