🚀 go-pugleaf

In an earlier article I cited some research of Jonathan Grudin that
demonstrated that the common interface design rule of "be consistent"
was sometimes best violated.  I gave some examples of my own.  This
theme has recently been picked up by Aaron Sloman of Sussex and Daniel
Kimberg of Princeton.  So perhaps it is time to see Grudin's own words
on the subject.

I originally gave the incorrect citation for the work: it is actually
an MCC tech report.  The paper was presented at a recent workshop on
HCI at which it received a controversial hearing.  Too bad.  I think
it an intelligent analysis of the topic and recommend it highly.  My
suspicion is that there are a lot of design rules, consistency being
one, but that these rules can sometimes lead to conflict. When
conflicts occur, the rules have to take on priorities, and it is here
that the consistency rule should sometimes be violated in favor of
some stronger, more important principle.  (Grudin and I are discussing
the possibility of writing a paper that expands on this theme.)  But
enough -- I asked Jonathan to provide a summary of his paper for the
net, and it now follows:

don norman
Donald A. Norman	[ danorman@ucsd.edu   BITNET: danorman@ucsd ]
Department of Cognitive Science C-015
University of California, San Diego

----------------------------------------------------------------------

Date: Sun, 5 Feb 89 15:06:49 CST
From: grudin@mcc.com (Jonathan Grudin)

This is a brief summary of an MCC Technical Report Number ACA-HI-002-89 
titled "the case against user interface consistency," mentioned by 
Don Norman. It is available from me (grudin@mcc.com) but will NOT 
be given at CHI'89 -- my paper there is "user interface design in 
large corporations: coordination and communication across disciplines."

"The case against user interface consistency" argues through a series 
of examples that "build consistent interfaces" is not a good design 
principle. First of all, where some kind of consistency is desirable, 
the hard part is discovering which dimensions to be consistent along.
For example, in abbreviating a set of two dozen command names, which
is the best algorithm: truncation, vowel deletion, or single-letter-at-
all-costs (even if it doesn't match the first letter of the command)?
As explained in the paper, any of these could be the best design solution,
it depends on aspects of the users' tasks. More importantly, consistency
is often not desirable at all. A recent proposal for an international
standard suggested placing the arithmetic function keys on numeric keypads
across the top row in the order +, -, x, / because "that is consistent
with the way we learn and remember these functions." True, but the most 
frequently used keys are generally the zero, ENTER, and plus keys,
and this placement would maximize the distance from the plus key to the
other two, thus maximizing the keying time and the likelihood of errors.
A better solution is the more standard arrangement, with the plus key
above the ENTER key, but this has nothing to do with "consistency," it
is based on knowledge of the hand, motor control, and the data entry task.

The paper also looks at menu defaulting and file management examples.

Finally, a good user interface consultant is likely to find that a
large, important part of the job consists of arguing AGAINST
consistency. Because some of the most controversial and difficult user
interface problems arise when the developers map the system
architecture onto the user interface: when the user interface is
consistent with the underlying implementation design but in conflict
with how the user sees things. Sure, a lot of interface problems are
due to careless inconsistencies, but when these are pointed out,
generally everyone gets the point; it is more difficult to get
designers to agree to user interface changes that are inconsistent
with underlying software modularization.

The negative message in the paper is that good design can't be found
by looking at formal properties of interfaces, by a "consistency
checking" or "consistency generation" program. The positive message is
that for all of the examples described, one approach will lead to the
design that is better than "consistent" designs. That approach is a
close examination of the users' and their work, broadly defined to
include sensory, motor, and cognitive psychology, users' work
environment as well as their computer-specific tasks, and a broad
picture of the system environment they will work within. This isn't
easy, especially for product developers who may envision a wide range
of users, but it is the approach that has to be taken. "Be consistent"
is only a good rule of thumb when you are working in relative
ignorance of your users and their work environments.

Jonathan Grudin
MCC
P. O. Box 200195
Austin, Texas 78720
grudin@mcc.com