COMPUTING PRACTICES

Edgar H. Sibley A survey of seventy-seven highly motivated industrial designers and

Panel Editor
programmers indicates that the iden Mica tion of specific, potential problems
in a human-computer dialogue design is difficult.

Improving a H&man-
Computer Dialogue
Rolf Molich and Jakob Nielsen

Any system designed for people to use should be easy

BANALITIES?
to learn and remember, effective, and pleasant to use.
Over the years there has been a considerable increase At first glance, the exercise used in the survey may appear
in designing interfaces that score highly on these issues. trivial. It is our experience that it is not so. You may find it
This experience has been documented in a number of worthwhile to do the exercise which appears in Appendix 1
guidelines for constructing good human-computer in- and compare your answers with ours before reading further in
this article. We have seen reasonable solutions produced
terfaces [5, lo]. Following these guidelines is commonly
within 30 minutes on the back of an envelope!
considered a necessary but insufficient condition for
constructing good human-computer interfaces.
Most often, following such guidelines during the de-
human-computer dialogue. In order to test the reader’s
sign phase imposes little extra effort on a development
understanding of basic features of good interface design,
project. Guideline reports, however, are often lengthy.
we designed the dialogue for simple display terminals
Documents of more i.han 400 pages are not uncommon.
which are still common in many administrative data
The mere size of a guideline report often means that it
processing systems: a display of 24 lines of 130charac-
is not consulted during design or design review simply
ters each and a keyboard; no color, no mouse, and no
because the work of locating relevant guidelines is not
graphics.
considered worth the effort.
This article describes a survey that we undertook to The Danish edition of Computemorld magazine pub-
investigate whether industrial data processing profes- lished the exercise as an informal contest under the
sionals would be able to recognize serious interface heading “The Unofficial Danish Championship in Dia-
problems in simple but realistic dialogues. Seventy- logue Evaluation [6].” To stimulate interest in the con-
seven designers and programmers from industry and test, a sponsor offered $700 in U.S. currency worth of
academia participated. Fifty-one were from industry, software for the best entry. The text of the exercise
10 were teachers or students from universities or high appears in an English translation in Appendix 1.
schools, and 16 had occupations that were not speci- The functional specification has been constructed
fied. Many of them were designers and programmers of solely for the purpose of the Computeworld contest and
administrative systems-the people who design, write, does not reflect any specific existing system. On the
and maintain our daily programs. other hand, each of the usability problems in the design
This article consists of four parts. We first present the can be observed in many systems in the real world.
survey and a number of conclusions from it. The sec-
ond part of the article presents the exercise used in the
The Participants
survey-a dialogue that we asked the participants to Seventy-seven entries were submitted with suggestions
evaluate as expressed in Appendix 1. The third part
for improving the human-computer interface of the ex-
contains our annotated solution as shown in Appendix ercise. Based on the professional appearance of many of
2 and a suggestion for an improved design as character- the submitted entries, we estimate that most of the
ized in Appendix 3.
participants used between two and five hours to com-
plete their entries. Several participants noted that they
FACTS ABOUT THE SURVEY had found the exercise worthwhile and revvarding in
The Exercise itself. These two facts lead us to conclude that the par-
We constructed an exercise in evaluating a simple ticipants were highly motivated, and therefo-re the re-
sults should be better than those produced b:y standard
01990 ACMOOOI-0782/90/0300-0338 $1.50 designers and programmers.

338 Communicationsof the ACM March 1990 Volume 33 Number 3

Computing Practices

PROBLEM CLASSIFICATION Provide Good Error Messages

We classified the usability problems in the dialogue in Good error messages are defensive, precise, and con-
accordance with a short checklist of usability consider- structive [9]. Defensive error messages blame the prob-
ations in a good dialogue. This checklist reflects our lem on system deficiencies and never criticize the user.
personal experience. The principles correspond to simi- Precise error messages provide the user with exact in-
lar principles described by others [l]. Almost all usabil- formation about the cause of the problem. Constructive
ity problems fit well into one of the categories. error messages provide meaningful suggestions to the
user about what to do next.
Simple and Natural Dialogue
Dialogues should not contain irrelevant or rarely Error Prevention
needed information. Every extraneous unit of informa- Even better than good error messages is a careful design
tion in a dialogue competes with the relevant units of that prevents a problem from occurring in the first
information and diminishes their relative visibility. All place.
information should appear in a natural and logical
order. EVALUATION PROCEDURE
All entries were initially evaluated by one person. The
Speak the User’s Language 13 best entries were subsequently reevaluated by two
The dialogue should be expressed clearly in words, other judges. All three judges then jointly selected the
phrases, and concepts familiar to the user rather than winner. There were only minor differences between
in system-oriented terms. the results of the initial evaluation and the reevalu-
ations.
Grading was very liberal. We gave credit for even the
Minimize the User’s Memory Load
simplest item that related to one of our problems. In
The user’s short-term memory is limited. The user
many cases, a point was awarded for a correct reformu-
should not have to remember information from one
lation of a message even if the general principle (for
part of the dialogue to another. Instructions for use of
instance, keep the user informed by providing appropri-
the system should be visible or easily retrievable when-
ate feedback within reasonable time) did not appear.
ever appropriate. Complicated instructions should be
An example: Problem 18 concerns the lack of feedback
simplified.
during 30-second database searches (problem numbers
refer to the detailed solution in Appendix 2). Here, we
Be Consistent awarded a full point for the suggestion, ltlform the user
Users should not have to wonder whether different that it may take as long as 30 seconds before the reply
words, situations, or actions mean the same thing. A appears, while no point was awarded for the statement
particular system action-when appropriate-should A response time of 30 seconds is simply unacceptable, be-
always be achievable by one particular user action. cause the statement does not indicate why the response
Consistency also means coordination between subsys- time is unacceptable or what could be done to alleviate
tems and between major independent systems with the problem.
common user populations [7].
COMMENTS ON OUR SOLUTION
Provide Feedback Our solution was constructed by carefully applying the
The system should always keep the user informed nine principles in the usability checklist presented ear-
about what is going on by providing him or her with lier in this article. The submitted entries caused us to
appropriate feedback within reasonable time. revise our original solution. We had overlooked two
problems: problem 14 (“Questions must be expressed
from the user’s point of view”) and problem 17 (“Coor-
Provide Clearly Marked Exits
dinate placement of error messages with the rest of the
A system should never capture users in situations that
system”). Problem 27 (” ‘Try again’ is meaningless”) was
have no visible escape. Users often choose system func-
expressed more precisely by a number of participants.
tions by mistake and will need a clearly marked “emer-
It is possible that our solution includes some bad
gency exit” to leave the unwanted state without having
points or that we have overlooked some problems. The
to go through an extended dialogue.
MANTEL system has not been subjected to empirical
tests to indicate how real users would use it.
Provide Shortcuts Problem 20 (“There may be no emergency exit from
The features that make a system easy to learn-such as the initial prompt”) and problem 22 (“It may not be
verbous dialogues and few entry fields on each dis- possible to edit input in the initial prompt”) have a
play-are often cumbersome to the experienced user. somewhat special character since many of the possible
Clever shortcuts-unseen by the novice user-may tools for implementing the Telephone Index system
often be included in a system such that the system would automatically offer the user these facilities.
caters to both inexperienced and experienced users. Since some tools do not provide such facilities, how-

March 1990 Volume 33 Number 3 Communications of the ACM 339

Computing Practices

ever, we need to have this requirement stated explic- are too vague”), but the author also expected credit for
itly in the system specification. problem 29 (“Accept other common forms of telephone
number as input”) and problem 31 (“Show (an example
Comments from the Participants of a telephone number in the initial prompt”).
After our solution to the exercise was published, we We think that this indicates that the problems appear
spoke to several people who wondered if we had over- insultingly simple when you read our solution but that
looked their solutions. These people had compared many of them are hard to express precisely. We have
their solution with our published solution and felt that little doubt that before the survey several elf the partici-
they had discovered more than 18 problems (the num- pants overestimated their abilities in the hurnan factors
ber of problems that the winner detected). In each case, area. There is a marked difference between actual and
we were able to convince the participant that our as- alleged knowledge of the elements of user friendly dia-
sessment of their solution was reasonable. logues. The strength of our survey is that it demon-
An example: One of the solutions stated: ILLEGAL strates actual knowledge.
NUMBER-Nonsense, of course, and also unfriendly. It
should say “The number cannot be correct,” but if would be
better to indicate what is wrong. Even more important: the WHAT SYSTEM DESIGNERS AND
input field can be constructed in such a way that the error PROGRAMMERS ACTUALLY KNOW
will almost never OCCMY. For this observation we gave The results of the survey are summarized in Table I
credit for problem 23 (“The word ILLEGAL may intimi- and Figure 1. The average number of problems men-
date the user”) and problem 24 (“The error messages tioned was 11.2 out of 30 problems (37 percent). The

Mentimed PlVbklll IJercr~tbn

by% IIIMIIY
95 15 Serious Re-displayinput (telephonenumber)with subscriberinformation
92 9 Avoidthe use of Englishterms if a Danishterm exists
92 10 Usethe Danishnationalcharacterswhereverpossible
77 4 Removeunnecessaryinformation
74 18 Serious Informthe user if it maytake30 secondsbeforea reply appears
73 5 Avoidmysteriouscharacters(>); considerusing field labels
64 8 The function keysshould be listed in somenaturalorder
64 24 Serious The error messagesare too vague
62 19 Serious The optionsavailableto the user should be displayed
58 3 Avoidspelling errors
The first nameshould be written beforethe last name
2; 2; Serious The error messagesshould be moreconstructive
38 11 Do not distort information(username)enteredby the user
32 12 Clarify or removeinformationthat is difficult to understand
29 The word ILLEGALmayintimidatethe user
27 5; “Enter numberand RETURN”may be takenliterally
18 31 Showan exampleof a telephonenumberin the initial prompt
17 6 Interspersedblank lines reducethe readabilityof an address
16 14 Questionsmust be expressedfrom the user’spoint of view
14 25 The systemshould tell how it has interpretedthe user’sinput
13 16 3 differentterms are usedfor “Telephonenumber”
12 13 The meaningof the notationPFl=HELPis not clearto novices
12 17 Coordinateplacementof errolrmessageswith the rest of the system
12 27 The request“Try again” in an error messageis meaningless
Avoidthe use of abbreviations
; 2; Allow lowercaseL and the letter 0 insteadof digits 1 and 0
8 29 Serious Acceptparentheses,spacesaind hyphen in telephone number
20 Serious Theremay be no emergencyexit from the initial prompt
t 21 Thereis no emergencyexit during a long retrieval
1 22 Serious It maynot be possibleto edit input in the initial prompt
TABLE 1
Summary of 77 entries submitted in a contest for evaluating a human-computer dialogue. For each
problem the table shows the percentage of the entries that identified the problem. Problem 1 does
not appear, since it was described in an example in the text of the exercise. The problem numbers refer
to the detailed solution in Appendix 2. Some of the problems may prevent some users from using the
system in a meaningful way. These problems are Imarked “Serious” in the table.

340 Communications of the ACM March 1990 Volume 3.3 Number 3

Computing Practices

winner mentioned 18 of 30 problems (60 percent). Our

expectations were somewhat higher, when one consid-
ers the nature of this study. Presumably, the only solu-
tions submitted were those which the authors felt were
good enough to stand some chance of winning. 27-30
Some of the problems may prevent some users from
using the system in a meaningful way. These problems 24-26
are marked “Serious” in both the table and in the solu-
tion in Appendix 2. The average number of serious 21-23
problems mentioned was 3.5 out of 8 serious problems
(44 percent). 1E-20 -1
Three problems score notably higher than the rest
(problems 9, 10, and 15). Over the last 15 years, there
have been several campaigns to make Danish designers 12-14
and programmers aware of the importance of using
Danish instead of English terms in computer output [8]. 9-11 ,’
The high score for problems 9 (“Use Danish terms”) and
10 (“Use Danish characters”) indicates that the cam- 6-Bimj’ ‘< ‘~
paigns may have been successful. It also indicates that
such campaigns may actually influence people. 3-5m ”
Many participants did not understand the meaning of
PORT073 and MANTEL INFO RELEASE 4.2. The pre- O-2& “’
vailing attitude of many respondents was that since I I I I I I
they did not understand it, they suggested that this 0 5 10 15 20 25
information should be removed. Only a few stated that
Nuderolatries
they had to know the exact meaning of this information
before deciding on whether it should be reformulated FIGURE 1
or removed. This diagram shows the distribution of the
Many entries indicated that the respondent consid- number of problems identified per entry in the
contest referred to in the article. The median
ered a questionable feature in the original design good
number of problems mentioned was 11 while
design practice. Several entries contained rephrasings
the average was 11.2 out of 30 problems. The
of the message “ILLEGAL NUMBER. TRY AGAIN!” that winner mentioned 18 problems. Problem 1
were more precise in pointing out the problem but was described in an example in the text of the
which still contained the questionable phrases “Illegal” exercise; therefore, any mentioning of prob-
and “Try again!” lem 1 is not included in this figure.
In our opinion, several of the suggestions for improv-
ing the interface hardly improved the interface. A few
entries correctly noted the spelling error in “subscriper” and propagating simple and intellectually manageable
but suggested that it be changed to another misspelling, requirements for the design product. These require-
such as “supscriber.” Other entries suggested barring ments could be similar to the nine principles we used
the user from entering incorrect telephone numbers by to construct our solution.
rejecting characters that were not digits using a beep as A good dialogue is error-tolerant and provides care-
an error message. A beep, however, is not a good error fully phrased informative messages in situations where
message. It is vague; it does not tell the user what to do the user may need help. Most specific interface prob-
next, and it is not expressed in the language of the user. lems can be either avoided or their consequences can
be minimized by suitable design of a system. The prob-
CONCLUSIONS lem categories covering this aspect of interface design
Gould and Lewis [4] have succeeded in expressing the are “Provide good error messages” and “Prevent errors.”
basic requirements for the design process in three short Except for problem 24 (“The error messages are too
principles: early focus on users and tasks; empirical vague”), none of the problems in these categories were
measurement; and iterative design. Gould et al. have mentioned in more than 42 percent of the entries. Fifty-
demonstrated the applicability and usefulness of these five percent did not mention any of the problems in the
principles in their design and development of the 1984 category “Prevent errors.” Only 8 percent suggested
Olympic Message System [3]. As indicated by some of that the system should accept other common forms of
the questionable suggestions for improvements that telephone numbers as input (problem 29); in our opin-
resulted from our survey, some designers may have ion, this is the most important problem in the category
difficulties in applying Gould and Lewis’ principle of “Prevent errors.” Regrettably, it is our conclusion that
iterative design appropriately unless they also have many designers and programmers are not sufficiently
similarly simple basic requirements for the design prod- aware of the importance of designing dialogues in a
uct. Our survey demonstrates the need for expressing way that would either prevent or tolerate errors.

March 1990 Volume 33 Number 3 Communications of the ACM 341

Computing Practices

A recent study of intelligent help systems [Z] con- aware of the necessity for extensive review of human-
cluded that ‘I. . .[The authors] are less confident that computer interfaces. As our own experience with the
the state of the art in user interfaces is clean enough to MANTEL system shows, the more people that look at
provide the kind of testbed we wanted.” Our study the interface, the more problems are detected.
seems to support this point. We have demonstrated that Computer systems are hard for most people to learn
industrial designers and programmers have considera- and use today. We believe that if human-computer dia-
ble difficulty in recognizing potential problems in the logues were designed by people who understand and
review of a simple human-computer dialogue. apply basic dialogue principles, they would achieve
What can we do to to solve this problem? The first much higher usability marks. The results ‘of our survey
and most difficult step is to realize that we are indeed indicate that many of these principles are neither com-
facing a serious problem. Human-computer dialogue mon knowledge nor intuitive.
construction appears deceptively simple, yet it is full of
subtle pitfalls as we have demonstrated. Second, some
intellectually manageable set of dialogue principles Acknowledgments. The authors would like to thank
should be proposed and its usability demonstrated, in a Peter Carstensen, Jan Clausen, Anker Hel:ms Jorgensen,
similar way to Gould and Lewis’ three principles for and Bodil Schroder for valuable comments on earlier
the design process. Third, designers should be made versions of this article.

Published Version
of Exercise
Appendix 1
REVISED DESIGN
GENERAL INFORMATION

V our task is to advisea companyaboutthe qualityof the human-computerdialogueof oneof its systems.Thecom-
panymanagementwantsto ensurethat noviceuserswill be ableto obtainresultsquicklywhenusingthe system.
With this in mind, you should point out as many (differentusability problems in the dialogue as possible.
Thebasicfunctionalityof the systemis fixed. Thepurposeof the exerciseis to criticizethe dialogueof the systemand
not its functionality Newfeaturesmightenhancethe usabilityof the system-but suggestionsfor newor changedfeatures
are not part of this exercise.
Yoursolution should consist of a list of all the usability problemsyou can find in the dialogue.You may also wish to
includesuggestionsfor howto improvethedialoguein orderto avoidthe usabilityproblems,andyoumayconsiderspecifying
an improveddialogue.Yourprimaryaimshouldbeto articulatethe usabilityproblemsyouhaveidentified,instea.dof merely
indicatingthem implicitly through subtle changesin an alternatedesign.
A Hint
We(the authors)haveidentifieda numberof usability problemsin this dialogue.Theexactnumberwill not be disclosed
hereexceptto saythat it is a two-digit number.
Tohelp you get startedand to indicatethe type of answersdesired,hereis one of the usability problemsas well as a
suggestionfor howto improvethe dialogue:“The screerldesignuses upper-caselettersonly, althoughwe knowfrom
humanfactorsstudiesthat mixed-casetext is muchmorereadable.It is OKto useupper-caselettersfor a lirnitednumber
of wordsthat you want to emphasize.”

T his systemis partof a servicefrom “ManhattanTelelahone” (MANTEL)’to homecomputerusers.Typica,lusershave

little knowledgeof data processing.Theycan dial into the system,which will providethe nameancladdressof a
telephonesubscriberin the UnitedStates,giventhe telephonenumberof the subscriber.
Tosimplifythe exercisewe makethe followingassumptions.Foreachtelephonenumberthereis, at most,onesubscriber.

‘The name “MANTEL” and the system have been invented for the sole purpose of this
exercise. Any relation to existing companies or existing information services is purr:ly
coincidental.

342 Communications of the ACM March 1990 Volwne 33 Number 3

Computing Practices

All telephonenumbersconsistof exactlyten digits (3-digitareacodeand7 otherdigits).The users computerhasa tradi-

tionalalphanumeric,monochromedisplaywith 24 linesof 80 characterseachanda typewriter-likekeyboardwith the usual
extrakeysfound on most computerkeyboards,including 10function keysmarkedPFI-PFIO.A displayis shownin the
illustration below.

PORT073 MANTELINFORELEASE4.a USER=JOHNSMIT 17-OCT-88 11:a7:a3

**..**~~~**.*********.~*~*****.***..**.****************
COMPUTER TELEPHONE INDEX
***.*****...***********..********************~**.******

THESUBSCRIPERIS

>
>JONES
>JIME.
>
>lTPINESTREET
>
>NEWYORX
>NYlOOl8

PFl=HELP PF2=DIRECTORYINFORMATION PFB=OTHERSERVICES

PFQ=VIDEOTEX

SPECIFICATION

The userentersthis systemby selecting“ComputerTelephoneIndex” from the main MANTELmenu.The systemthen

issuesthe following prompt:
ENTERDESIRED
TELEPHONE
NO.ANDRETURN
If the user entersanythingother than exactlyten digits in responseto this prompt,the systemanswers:
ILLEGALNUMBER.TRYAGAIN!
If the user entersa telephonenumberwhich is not in use,the systemanswers:
UNKNOWN
TELEPHONE
NUMBER
If the areacodeof the telephonenumberis 212(theareacodefor Manhattan),the systemwill normallydisplaythe screen
shownin the figure within five seconds.Forother areacodes,the systemmust retrievethe necessaryinformationfrom
externaldatabases;this maytake up to 30 seconds.

Appendix 2

T his simplesystemactuallycontainsat least29 usabilityproblemsin its dialogue.Theoriginal Danishversionof the

exercisecontained31 usabilityproblems;however,wehavenot beenableto translatetwo of the usabilityproblems
(problems9 and 10)into English.Thenon-translatableproblemsareincludedin the list to givean ideaof language-related
interfaceproblems.Notethat problem1 is includedas an examplein the text of the exercise.

March 1990 Volume 33 Number 3 Communications of the ACM 343

Computing Practices

PRoBLEM26.(serious) The error messagesare not constructivesincethey do not tell the user howto colmct the er-
ror.Forexample,onecouldsupplementthe error message$rst mentionedby “Entertelephonenumberasten digits with
the areacode as the first three.”
PRoBLEM27. It is meaninglessto askthe userto “Tryagain!”in an error messagesincethe computerwill giveexactly
the sameresultthe nexttime. A bettermessageis “Try againwith anothertelephonenumber,”but the best is probably
to drop this altogether.

PREVENT ERRORS
PRoBLEM26. This systemis to be usedby somepeoplewho may be totally newto computers.Therefore,it is likely
that someusersarenot usedto the sharpdistinctionin computersystemsbetweenthe letters“I” (lowercaseL) and“o”/“O”
(loweror upper-case0) on the onehandandthe digits “1” (one)and “0” (zero)on the otherhand.If the systemencounters
one of these letterswhereit expectsa digit, it should providea helpful messageor simply replacethe letter by the cor-
respondingdigit.
PROBLEM29.(serious) Insteadof havingerror message.s for input with parenthesesaroundthe areacodeor with ex-
tra spaces,the systemcould just acceptthese commonwaysof enteringtelephonenumbers.
f666LEM36. Experienceshowsthat somenoviceuserstakethe prompt “Enter numberand RETURN”quite literally
and type R-E-T-U-R-N.
It is betterto write “. .and pressthe RETURNkey.”
fftOBLEM31. Thecommunicationfrom the systemto the usershould not be keptin abstractor theoreticalterms but
shouldbesupplementedby concreteexamples,whichoftenincreasethe users’understandingconsiderably.In the prompt
“Entertelephonenumberand pressthe RETURNkey:,”an exampleof a telephonenumberin the simplestform accepted
as input by the systemsshould be added-even if this form is differentfrom the output format usedby the systemto in-
creasereadability(seeproblem15).Thetelephonenumberusedin the exampleshouldeither not be in use or it should
be a numberof the ManhattanTelephoneOperator.

Appelndix 3

TELEPHONE INDEX
.*******************.*.~*..*.**.************

Telephone number (515) 345-5759 has the following sulbscriber:

Jim E. Jones
17 Pine Street
New York, NY 10012

Press:
RETURN to be able to enter a new telephone number
ESC to leave the Telephone Index
PFl to get Help about how to use this system
PF5 to go to the Directory Information system
PF4 to go to the general Videotex service
PFS to get a list of Other Services available

346 Communications of the ACM March 1990 Volume 33 Number 3

Some of the problems may prevent some users from using the system in a meaningful way. These problems are
marked “Serious.”

SIMPLE AND NATURAL DIALOGUE

PROBLEM 7. The screen design uses upper-case letters only, although we know from human factors studies that mixed-
casetext is much more readable. It is OKto use upper-case letters for a limited number of wordsthat you want to emphasize.
PRoBLEM2. If there is room, you should write out the entire word instead of using abbreviations. Thus, “October” is
preferable over “Oct.”
PROBLEM3 Spelling error: “SUBSCRIPER” should be “subscriber.” Spelling errors distract users and make them suspect
a generally poor quality of the system.
PROBLEM4 The USERNAME is unnecessary information since it must be assumed that users know who they are, even
without being told by the system. In an information system for telephone numbers, the date and time are also unnecessary
bits of information. See problem 12.
PROBLEM 5. The characters “ >” are mysterious-especially at the blank lines. An alternative might be to show the
field labels instead. This would also make it clear why some of the fields are not filled in. In the case of name and address,
however,the meaning of the fields will be obvious to any user if we remove the “ >” and change the order of the fields
as discussed in problem 7.
PRoBLEM6. The blank lines in the middle of the information reduce the readability and may confuse the user.Therefore,
we should restructure these fields so that lines without information are suppressed rather than output to the user as blanks.
In the example in this exercise, this means that we should skip the fields for c/o address, etc.
PROBLEM 7. The first name should be written before the last name since this is the natural ordering. Furthermore, the
system should present the user with a single-merged name field instead of two separate fields for first name and last name.
It is of no interest to the user of this system how the database is structured internally. The same goes for the city name,
state, and zip code.
PRoBLEM8. The function keys should be listed in some logical order, e.g., numerically. The blank space between PF2
and PF5 should be eliminated.

SPEAK THE USER’S LANGUAGE

PROBLEM 9. This problem does not appear in the English translation of the exercise. Avoid the use of English terms
if a proper Danish term exists. Use the Danish abbreviation “Okt.” instead of OCT.Replace HELP with the Danish term
“Hjaelp” or “Forklar” (Explain).
PROBLEM 10. This problem does notappearin the English translation of the exercise. Use the Danish national characters
a? and 0 instead of the Swedish or German equivalents a and a.
PROBLEM 11. From the USERNAME in the example it appears that the system truncates the user’s name to eight
characters. In general, computer systems should allow users to enter user and file names of any reasonable length. Other-
wise, the system will either force users to use unnatural abbreviations or distort the information entered by the user by
only making use of the first N characters.
PROBLEM 12. The information PORT073 and MANTEL INFO RELEASE4.2 may be difficult to understand for many users.
Since this information will rarely be needed by ordinary users, it may be either deleted or moved to a separate display
where it may be explained in more depth. In distinguishing between problems 4 and 12, the keywords that we looked for
were “unnecessary” for problem 4 and “difficult to understand” for problem 12.
PROBLEM 73. The system uses the notation “PFl=HELP” to explain the use of the function keys. The meaning of this
notation-in particular the use of the equals sign-is not clear to novice users. On the other hand, it is easy to understand
for users who know about function keys and who have seen the notation in other systems. It is a compact notation which
is an advantage in systems which must display much more information on each screen than is the case in this system.
It is not obvious which solution to suggest since the need to explain things in detail for the novice user contrasts with
the need to be consistent with the notation known by experienced users from other systems. Because of the specific em-
phasis on usability for novice users in this system, we prefer the solution which is better for novices.
PROBLEM 74. Questions to the user must be expressed from the user’s point of view and not from the system’s point
of view.The initial question should not be “Enter desired telephone number.. .‘I, since the user does not want the telephone
number but rather name and address. The initial question should be something like “Enter telephone number for which
you want name and address.”

MINIMIZE THE USER’S MEMORY LOAD

PROBLEM 15. (serious). The telephone number entered by the user should be displayed together with the subscriber
information. The telephone number should appear in a format that is well-known by the user and accepted as input by
the system.

BE CONSISTENT
PROBLEM 16. Several different terms are used for the same concept: Number, Telephone No., and Telephone number.
PROBLEM 7Z The specification does not state where error messages are displayed on the display. It should be em-
phasized that all error messages should be displayed in the same location. Since the current system appears to be a sub-
system of some general information system, the format and placement of error messages should be coordinated with
the rest of the system. Similar coordination considerations apply to the general screen layout, function key assignment,
and wording.

PROVIDE FEEDBACK
PROBLEM 78. (serious) A response time of 30 seconds to a command from the user is unacceptable. For technical
reasons it may take the system as long as 30 seconds to retrieve the requested information from external databases. To
tell the user what is going on and to show that the system is active, however,the system should display a message like
“Telephone number (203) 456-7890 is outside the 212 area code so it may take up to 30 seconds to retrieve the informa-
tion.” Every five seconds the system should also display some indication that it is still working on the command.
PROBLEM 19. (serious) The screen contains no information about what users should do once they have read the infor-
mation and want to continue.

PROVIDE CLEARLY MARKED EXITS

PROBLEM29 (serious) There is no indication of how users may exit from the system without answeringthe intitial prompt
to enter a telephone number.
PROBLEM21. When users request information about a telephone number outside the 212 area code, the system may
take up to 30 seconds to answer.The system should provide a facility for aborting the information retrieval.
PRoBLEM22. (serious) The system specification does not indicate whether the user can edit a partially entered telephone
number. It is an essential “emergency exit” to allow users to use the BACKSPACEkey, for example, to correct errors in
a text they have typed.

PROVIDE SHORTCUTS
(In the English version it would be reasonable to accept user input consisting of only seven digits with a 212-area-code
default for the expected large number of local requests. Because of the structure of Danish telephone numbers, a similar
suggestion would not be appropriate for the original exercise.)

PROVIDE GOOD ERROR MESSAGES

PRoBLEM23. The system should not use the word “ILLEGAL” in an error message. Users do not break the law because
they enter a wrong number. In any situation, the system should not intimidate the user by suggesting that he or she must
be stupid to make such a mistake.
PRoBLEM24. (serious) The error messages are too vague. The system should inform the user as exactly as possible
about what it knows about the problem-for example, if the area code is missing.
PRoBLEM25. The system should report back to the user howit has interpreted his or her input. An example: “The system
cannot understand the telephone number W3 QV.”This is especially important in this system which is accessed by users
via a modem and possibly noisy telephone lines. Users have a right to know whether a problem is due to a transmission
error or a user mistake.
Computing Practices

SPEClFlCATlON
The user entersthis systemby selecting “TelephoneIndex” from the main MANTELmenuas shown. The systemthen
issuesthe following prompt:
Entertelephonenumberand pressthe RETURNkey:
Exampleof a telephonenumberwhich the systemunderstands:212456 7890
Youcan stop this systemat any time by pressingthe ESC-key
Characters enteredbythe useraredisplayedimmediatelyto the rightof the colonafter“RETURN
key” in the abovemessage.
As long as the user has not pressedRETURN,the latest characterwhich has beenenteredbut not yet deletedmay be
deletedby pressingthe BACKSPACE key.
Anywherein this systemwherethe user may pressthe RETURNkey,he or she may chooseto press ESCinstead.
ImmediatelyafterESChasbeenpressed,the systemwill leavethe “TelephoneIndex”withoutfurtherprocessingof previous
user input.
Analysisof input starts when the user pressesRETURN.This analysisdoesthe following:

l The systemignoresspacecharacters.
l The systemignoresa hyphenbetweenthe third and fourth digit and betweenthe sixth and seventhdigit.
l The systemignorescorrectly matchedparenthesesaroundthe first three out of ten digits (the areacode).
l The systemreplacesany occurrenceof the letterso or 0 (loweror upper-case0) by the digit 0 (zero).
l The systemreplacesany occurrenceof the letter I (lower-caseL) by the digit 1 (one).

If thetelephonenumberenteredbythe userconsistsof exactlysevendigits,the systemwill assumethat the userwants

informationaboutthe giventelephonenumberin the 212 areaand that the user has omittedthe areacode 212.
If the telephonenumberenteredbythe usercontainssyntaxerrorsaftercompletionof the aboveanalysis,the system
will reply with the message:

The systemcannot understandthe telephonenumberW3 OV

Entertelephonenumberas ten digits with the areacode as the first three.
Example:212456 7890
Pressthe RETURNkeyto continue

In this examplewe haveassumedthat the user enteredthe charactersW3 QVas a telephonenumber.

If the user entersa telephonenumberwhich is not in use, the systemreplieswith the message:

The telephonenumber(212)456-7890is not in use

Pressthe RETURNkeyto continue

If the areacodeof the telephonenumberis 212(theareacodefor Manhattan),the systemwill normallydisplaythe screen

shownin the figure within five seconds.Fornumberswithin other areacodes,the systemretrievesinformationfrom ex-
ternal databasesand maytakeup to 30 secondsto displaythe screen.Whenthe userhasenteredRETURN,the system
will displaythe following messageon the screen:

Telephonenumber(203)456-7890is outsidethe 212areacodeso it maytake up to 30 secondsto retrieve

the information.
Pressthe ESC-keyif you want to STOPthe searchfor this information

Everyfifth secondthe systemwill addan extraperiod(.) to the right of the last periodto the right of “to retrievethe infor-
mation.”
Themessagesdescribedin this specificationareoutput startingfrom line 19.Beforeoutputtinga message,the system
blankslines18-24 completely.Whenthe userpressesRETURN or ESC,or whena searchis complete,the messagedisap-
pearsandthe systemrestoresthe previouscontentsof lines18-24. Aftera usererror,the systemthen returnsto its initial
stateand continuesby outputting the initial prompt.

March 1990 Volume 33 Number 3 Communications of the ACM 347

Conrptrtirrg Practices

-
AROUT THE AIJTIIORS:

ROLF MOLICH works for the Ballica Insurance Company in

Copenhagen. thn~nark. ~vhere he is manager of and-user rcla-
lions al Lhe Dcvclopnicnt Scrvicc Center. He also leaches hu-
man-c:ompulcr interaction at the Technical Universily ol’ JICII-
mark. Author’s Prescnl Address: Baltica A/S. 41ail Code B22.
Klausclalsbro\wj f3)l. DK-2750 Ballerup. Denmark.

JACOB NIELSEN is an assistanl professor at the Technical

I!nirersitv of Denmark. Iiis current rcscarch interests are usa-
bility engineering and hypcrtcxt. Author’s Prcscnt Address:
Department of Computer Science. Building 3.1-1. Technical I:ni-
versity of Denmark. I)K-2800 Lyngby. Denmark.
DATJh@NEI!\‘Ml .BITNET.

CR Categories and Subject Descriptors: D.2.2 [Software Engineer-

ing]: Tools and Tcchniqucs: H.1.2 [Information Systems]: User hlachiuc
Systems
General Terms: Design. Human Factors
Additional Key Words and Phrases: Consistcncv. dialogue design.

ACM SPECIAL INTEREST GROUPS

AREYOURTECHNICAL SIGCAPH Newsletter. Cassette Edition SIGMICRO Newsletter
INTERESTSHERE? (Xlicroprogramming)
SIGCAPH Newsletter. Print and Cassctto
Editions SIGMOD Record (hlanagemcnt of Data]
The ACM Special Interest Groups further the ad- SIGCAS Sewsletter (Computers and SIGSUM Newsletter (Numerical
vancement of computer science and practice in Society) Mathematics)
many specialized areas. Members of each SIG
receive as one of their benefits a periodical SIGCHI Bulletin (Computer and Human SIGOIS Newsletter (Office Information
exclusivelydevoted to the special interest. The Interaction) Syslems)
following are the publications that are avail- SIGCOMM Computer Communication SIGOPS Operating Systems Review
able-through membership or special Review (Data Communication) (Operating SystemsJ
subscription.
SIGCPR Newsletter (Computer Pcrso~mzl SIGPLAS Notices (Programming
Kesearch) _. -
Languages)
SIGACT NEWS (Automata and SIGCSE Bulletin (Computer Science SIGPLAN FORTRAN FORUM (FORTRAN)
Computability Theory) Education1
SIGSAC Sewsletter (Security. Audit.
SIGCUE Bulletin (Computer Uses in and Control)
Education)
SIGAPL C!uote Quad (APL)
___--. _. . SIGSAM Bulletin (Symbolic and Algebraic
SIWJA Sewsletter (IJes
‘- ign Automation)
SIGARCH Computer Architecture News lvianipulation)
(Architcct& of Computer Systems) SIGDOC Asterisk (Systems
SIGSIM Simuletter (Simulation and
Documentation)
SIGART Newsletter (Artificial \,foclcling)
Intelligence) SIGFORTH Newsletter (FORTH)
SIGSMALL/PC Newsletter (Small and
SIGBDP DATABASE (Business Data SIGGRAPH Computer Graphics Personal Computing Systems and
Processin::) (Computer Graphics] Applications)

SIGBIO Newsletter (Biomedical SIGIR Forum (Information Retrieval) SIGSOFT Software Engineering Notes
Computing) (Software Engineering)
SIGMETRICS Performance Evaluation
SIGCAPH Newsletter (Computers and the Review (1leasurement and SIGUCCS Sewsletter (University and
Physically Handicapped) Print Edition Evaluation) College Computing Services)

See the ACM membership application in this issue

for additional information.