This is a guide to computers about how to communicate well with humans. The problem is difficult because humans are extremely complex, diverse, imprecise, and unobservant creatures. Often, a terse, carefully worded message will be misinterpreted. Long, detailed explanations will not be read completely. And usually, notices about errors made by humans will be turned around and redirected as shortcomings of the computer. Several things can be done to address these issues. Each will be discussed in the following sections.
Although humans constantly use spoken and written words to communicate with each other, they tend to do it rather poorly. Precise statements are not enough. You must strive for clarity and understanding.
Jargon and Acronyms and Abbreviations, Oh My!
Computers are replete with jargon, such as acronyms and abbreviations that exist in no other context. Most humans on the planet have not a clue what any of them mean. Translate jargon into plain words and phrases, even though it will result in longer statements. Few of them could tell you what "boot" means. Some acronyms, such as URL, are commonplace now, but use them with extreme caution. Be redundant. Combine common acronyms with the equivalent in real words. "The address of the Web site, its URL, is www.envoyww.com." In this way, you will be teaching as well as communicating. People within a culture are comfortable with some of the common abbreviations in their language. The problems here are that you cannot tell who knows what abbreviations, and people whose first language is different from that of your Web site will have more difficulty translating an abbreviation than the actual word. All three of these elements require the human to divert some of his limited mental processing to decoding the cryptogram. Therefore, just say it straight out with real words in well-formed, grammatically correct sentences.
Technically Speaking, Don't
While trying to communicate precisely, computers often employ precise terms specific to the domain of computers. Although this is technically correct, it is wrong for humans because they do not share the same vocabulary domain as computers. The exception is the small subculture of humans who program computers. Communicating with them is easy because they have learned the technical vocabulary related to computers. Most of the human population does not understand the terms file, memory, link, address, disk, CPU, session, or hard drive as they apply to computers. This seems incredible to the few who truly understand the terms in that contextthis is precisely the crux of the problem. People use the computer as a tool, a vehicle of information. They don't know how it works. They don't know what is inside of it. They do know how to make it convey the information they want. The same concept holds true for other technologies. Consider the automobile.
Learn the Language of Their Business
Just as people become disoriented, confused, and embarrassed when confronted with strange words or with familiar words in a strange context, they appreciate communication that employs the special vocabulary of their fields of interestfor instance, financial professionals like ROI and APY (hint, it's not a comedy duo). When presenting information to professionals, consider the problem domain in which the person works. It's OK to use their jargon, acronyms, and abbreviations. If you need to communicate information about one of their objects, use its name or classification as appropriate. For example, when tempted to state "File XYZ.CSV not found," try using "The exported address book labeled XYZ.CSV, could not be found in the Exports folder located at C:\Data\Exports." Sneak the technical stuff into a context they can relate to.
Most computer users tend to neither ask for directions nor read instructions. This presents us with a communication challenge, but we must guide them nonetheless. The most effective method is to provide directions that do not appear to be directions.
Nonverbal Communication Speaks Louder than Words
The human brain has two hemispheres, each with a tendency toward specialized functions. The right is sometimes referred to as "nonverbal" and the left as the "locus of language." Both of these labels are gross misrepresentations, even though they have some basis in fact. The right side tends to process the "big picture," whereas the left side produces a precise interpretation of the language. We should "speak" to both sides. Controls should exhibit correct affordance for interactions. Push buttons should look like buttons to be pushed. Thus, directions such as "Push this button" are not required. People have learned that text underlined in blue on a Web page indicates a hyperlink that will display a new page if clicked. We no longer have to guide them with "click here." In fact, doing so may seem condescending to some people.
Most languages are read left to right and top to bottom. Controls presented in this sequence will be processed in language-based order without the need for sequence numbers. Numbering the steps in a different sequence will cause great confusion. Although this may be amusing to watch, resist the temptation.
Icons and pictographs present a special challenge. They will be processed in the right hemisphere. If we label the icon, the words will be processed in both hemispheres. The right is capable of handling the multiple meanings of the words. The left will select a specific meaning, hopefully one that makes sense given the context. If the two hemispheres disagree on the correct meaning of the icon, we have a communication problem. Icons are greatly influenced by culture, experiences (computer and real-world), education, and age. All icons should be labeled. Even if the two hemispheres disagree, at least they will be talking with each other.
Providing Unsolicited Help, Gently
Remember that most humans, especially males, do not welcome help. However, most humans, especially males, crave information. Brief, well-worded explanations about the presentation of controls, objects, and the current task could be most useful if presented unobtrusively and in a manner that helps to confirm the person's understanding about what is happening. Be specific. Use people words, not computer words.
If specific information is required from them, make that clear. Use verbal and nonverbal clues to draw attention to the place where they specify the information. A small asterisk with an explanatory footnote is insufficient.
Request Guidance; It Helps Them Feel in Control
Often, very often, the human offers incomplete, inconsistent, or incorrect information. Rather then scold them for their carelessness, ask for clarification of the information. "What is the area code?" is better than "Error in input: Area Code invalid."
There comes a time during all interactions with humans when we have to inform them they made a mistake. Regardless of how you do it, they will blame the computer. It is part of human naturesomething about cognitive dissonance.
They Are Never WrongJust Misunderstood
This is the primary rule: the user is always right even if we don't have a clue what they are trying to do. When an error condition is detected, simply state the situation in their language. Explain the specific test that detected the situation, translating all technical terms and data as best you can. For example,
The telephone number asd798f5 is not a valid telephone number. Letters are not permitted in a telephone number. Telephone numbers should be 10 digits including a three digit area code followed by a seven digit number. For example, 9786700023 is a valid telephone number.
This is better than what you really want to say: "Number illegal." Or "Unknown phone number." First, no one will be arrested for typing a wrong number, so it's not illegal. Neither is the number unknown, an ambiguous word. It's just not a number. The preceding example is stated in complete sentences. It offers them feedback about what we understood the user to type and the rules the data violated. The blame is placed on the data, not the user. If you think this is similar to the way they treat their children then you are beginning to grasp the concept.
Guide Them Out of Confusion
After delivering the bad news, suggest what the human can do about it. In the preceding example you could say "Re-enter the 10-digit telephone number and then click on the Save button." It is comical to leave the last phrase out, watch a user re-enter data, and just sit waiting for the computer to go on. However, humans don't like being made fun of, especially by a machine, so give complete directions. If specific alternative actions could be taken by clicking on links or buttons, offer the controls right in the error-message-handling directions. Don't make them hunt for the controls elsewhere on the page. Remember, they are already confused and embarrassed; don't rub it in.
People like affirmations. They require closure. They demand feedback. They need reminding about what they are doing.
Provide Feedback to Relieve Anxiety
If the user asks for something to be done, and you do it, state what you have done. For example, in a message-sending application, if the user asks for a draft message named Notice of Policy Changes to be used, include the following confirmation message on the page: "Draft Message: Notice of Policy Changes, loaded for editing." In addition, after sending a message, state "Notice of Policy Changes message sent," rather than the "one size fits nobody" message "Message Sent." People want to know that the computer is doing what they wanted done.
Remind Them What They Asked For
People work with named objects. Include the name of the object the user is working with on the current page. If the user is sending a message, include the message title or subject on each page of the send message process. People forget what they are doing. Deal with it.
Proclaim Your Success and They Will Feel Proud of Themselves
When each step of a task or a whole task is completed, let the user know. Be specific about what has been done. This will help them to feel a sense of accomplishment. Humans like success, even if the computer really does all the work.
Envoy WorldWide, Inc.
46 Manning Road
Billerica, MA 01821-3916
©2001 ACM 1072-5220/01/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 © 2001 ACM, Inc.