3.1177 everyday psychology and design of software (84)
Willard McCarty (MCCARTY@vm.epas.utoronto.ca)
Thu, 15 Mar 90 20:16:44 EST
Humanist Discussion Group, Vol. 3, No. 1177. Thursday, 15 Mar 1990.
Date: Wed, 14 Mar 90 13:27:00 EST
From: TRACY LOGAN <LOGANT@lafayett>
Subject: The Psychology of Everyday Things
Since it didn't turn up in a database search of the Humanist
archives, I'd like to recommend the book The Psychology of
Everyday Things, by Donald Norman. It is well-written, compact,
non-technical, and delightful. Those HUMANIST members whose
craft is providing computer services might find Norman's ideas
useful, and those who are provided such services might find
solace or ammunition. (Basic Books, 1988)
An extract to give the book's flavor:
I once was asked by a large computer company to evaluate a brand
new product. I spent a day learning to use it and trying it out
on various problems. In using the keyboard to enter data, it was
necessary to differentiate between the "return" key and the
"enter" key. If the wrong key was typed, the last few minutes'
work was irrevocably lost.
I pointed this problem out to the designer, explaining that I
myself had made the error frequently and that my analyses
indicated that this was very likely to be a frequent error among
users. The designer's first response was: "Why did you make
that error? Didn't you read the manual?" He proceeded to
explain the different functions of the two keys.
"Yes, yes," I explained, "I understand the two keys, I simply
confuse them. They have similar functions, are located in
similar locations on the keyboard, and as a skilled typist, I
often hit "return" automatically, without thought. Certainly
others have had similar problems."
"Nope," said the designer. He claimed that I was the only person
who ever complained, and the company's secretaries had been using
the system for many months. I was skeptical, so we went together
to some of the secretaries and asked them whether they had ever
hit the "return" key when they should have hit "enter." And did
they ever lose their work as a result?
"Oh, yes," said the secretaries, "we do that a lot."
"Well, how come nobody ever said anything about it?" we asked the
secretaries. After all, they were encouraged to report all
problems with the system.
The reason was simple: when the system stopped working or did
something strange, the secretaries dutifully reported it as a
problem. But when they made the "return" versus "enter" error,
they blamed themselves. After all, they had been told what to
do. They had simply erred.
Of course, people do make errors. Complex devices will always
require some instruction, and someone using them without
instruction should expect to make errors and to be confused. But
designers should take special pains to make errors as cost-free
as possible. Here is my credo about errors: If an error is
possible, someone will make it. The designer must assume that
all possible errors will occur and design so as to minimize the
chance of the error in the first place, or its effects once it
gets made. Errors should be easy to detect, they should have
minimal consequences, and, if possible, their effects should be
reversible.
Those who subscribe to lists that, unlike HUMANIST, are not
moderated, are all too familiar with an event that generates
this oft-heard plea:
> WHEN YOU WISH TO BE ADDED/DELETED TO A MAIL-GROUP THAT IS HANDLED
> THROUGH A LISTSERVer, PLEASE, PLEASE SEND THAT REQUEST TO
> LISTSERV AND NOT TO THE LIST [from February's NETMONTH],
The parallel seems close. -- tracy