We create meaning by placing words in a context where they absorb their surroundings like herring in a sherry marinade. Use a word in a context that supports clear understanding of the intended meaning, and you make the word richer and stronger for yourself and for the time when someone else takes her turn at using it. Overlook your intended meaning, and you defocus the imagescatter the energyof the word.
Word meanings can change over time; that's all well and good. "Awful" used to mean "full of awe," and seven centuries ago "nice" meant "foolish" (some might say it still does!). The rich garden of English vocabulary has grown from the endless planting of new words from foreign sources, jostling for their place in our prose and poetry. A living language is always on the movegood thing for us.
There's a bit of a problem, though, when we want a word to conjure up something more concrete than a poetic image in the reader's mind. When we want to use a word as terminology. Terminology is to vocabulary as bulldog is to kennel: It demands a certain kind of care. We want a term to hold its value. It has to say the same thing to everyone who needs to read or hear it.
With that in mind, let's take a look at some usability terms and how their meanings might be compromised.
- Intuitive: It is said "The only intuitive user
interface is the nipple"and how that might be is not
within the scope of this article! Once we move beyond the primal
food supply to more contrived appliances, the decision about what
is intuitive and what is not becomes a lot more difficult. If
intuitive means natural, in the sense that
comprehension requires no thinking, where is the division between
those things that are natural and those that are
This isn't just nitpickinga rich and evocative word like intuitive is wasted as long as it sits in a fog of uncertain associations. So let's help rescue it by saying this: An intuitive interface asks no more of a user than what he either already knows or can immediately deduce from previous life experience. Implied is that intuition, as a term in usability, is wisdom assumed and shared within a communitythe community of users familiar with the task and with the environment in which it is performed.
No Windows program, for instance, could bear the burden of being "intuitive" to someone who's never before seen a Windows program! What use, for instance, is that little "ridged" wedge at the lower right corner of a resizable window to someone who doesn't recognize it as a grip (from life experience with real grips) to click and drag (from familiarity with Microsoft Windows®)?
- User-friendly: This antiquated term dates back to a
time when there wasn't much distinction between someone who knew
applications and someone who knew computer systems. As
applications began to be used by people whose lives were not
immersed in computing, the assumptions made by developers about
what the user knows had to change dramatically. Developers
thought of users as constraintsill-informed and hostile
ones, at thatand they reluctantly cobbled user interfaces
together as concessions to crankiness.
We've moved on since the days when anyone who worked with computers was thought to know it all. Specialists in graphic design, interaction design, human factors, typography, database, hypertext, documentation, and task-specific programming languages all contribute jointly to a successful design. Every specialist will have his or her agenda for the project and a personal picture of the user and what that user might think of as friendly behavior. Is fast response friendly or just a Good Thing? Are clearly labeled icons friendly or just easy to understand? If the application controls a nuclear reactor, will the user care if a control screen is friendly if it's easy to comprehend and it's fast acting?
Users don't want the computer as a friendthey want it as a tool that will do stuff for them.
- Logical: An application that is logical in its
internal design and produces accurate results may nevertheless be
difficult to use. Of all the pitches you could devise to sell the
merits of an interface, logical might be the most
persuasive. On the surface of it, how could you argue against
anything being logical? Welltry asking whose logic has
been applied and why. Is it the logic of the analyst who broke
the task into parts? Is it the logic of the programmers who coded
input fields in alphabetical order because they weren't told what
was wanted? Is it the logic embedded in the design of a legacy
database, created by someone who retired to a cabin in the
Rockies 10 years ago?
All of those practitioners had a reason for building their product the way they didreasons that seemed sound to them at the time and within the scope of their work. But their logic applies to the internals of the applicationthe plumbing within the walls. If you find one sink in your house with the hot and cold backwards, you aren't going to be very sympathetic when the plumber says it made his life easier to leave it that way!
- Heuristic: This word often appears in usability
paperwork in the phrase "heuristic evaluation." A
heuristic evaluation is a critical scrutiny of the interface by
trained examiners who look for potential problems that a user
might have, with reference to guidelines derived from research
and practical experience (the heuristics). The guidelines may be
a list of desirable features that the examiners look for and
comment on, or it may be a full-blown rubric of the sort teachers
use for student assignments.
Unfortunately, "heuristic evaluation" has become a catchall label for several kinds of inspection. The point is that heuristics are general principles; they are not the only kind of guidelines on which a usability inspection can be based. For example, when an interface must conform to a standard set by a project or contract, that standard can be very specific in its requirements, going way beyond heuristics. If that standard embodies usability principles, you're doing a usability inspection. Let's reserve "heuristic" evaluation for when we have used general heuristics and not some other evaluation criteria.
- Subjects: This term comes to the usability field from
human factors research, where studies compare design features and
their support for human performance (effectiveness and
efficiency) and safety. The term has been used even longer in
medical and educational and in psychological research, whose
studies use "human subjects" to test and compare the
safety and effectiveness of treatments (pharmaceuticals, surgical
methods, instructional materials, counseling methods).
However, the usability engineering community has come to view the people who participate in our studies not as subjects but as partners. To us it seems that calling them "subjects" dehumanizes them and discounts their contributions to the work. There are other differences as well: Usability tests do not deliver "treatments" to see how "subjects" improve or change; instead, we collect users' feedback and impressions of our products (subjective satisfaction) as well as look at the overall performance of the interaction between the two. Users' opinions count.
In addition, usability testing yields the most valid results when the users who participate have the feeling of using the product "naturally," as they would in their typical setting (office, home, etc.). We have found it important to stress to them that it is not they who are being tested, but that they are helping us test the product. We do not want the testing itself to put pressure on them, beyond what they would feel from just using the product to do whatever they use it for. The usability community generally believes that treating them as "subjects" can increase the pressure to perform. Most usability engineers call these people "participants" to reflect this perspective.
- Subjective: The statement "Design is all
subjective" is flat wrong. This word subjective pops
up repeatedly in reference to the design of consumer items from
toasters to stereo equipment to Web sites, with the intent to say
that there are no firm rules or principles governing the design
process or the quality of its results. Everything is up for
grabsthe user is fickle; the intent is to capture
attention and differentiate oneself with novelty.
People who say that design is all subjective are not talking about design for usabilitythey are talking about style. Where Web sites are concerned, style is a major factor in successfully pitching a product or a point of view against a background of competition. Style is vital to brand identification.
Not all user interfaces are billboards, though, and usability is far more than style. When the computer controls a vehicle, a power plant, a million-dollar accountthe user in front of the display is presumably sold on the importance of the task, and what remains is to get that task done as smoothly as possible. The user is the operator of a machine doing a job. The interface to that machine doesn't have to grab attention or entertainit has to facilitate accurate and efficient work. You don't design interfaces like that by having the graphic arts department try Miracle Pink for the first time, no matter how much they like it. There is a time to be pleasing, but this isn't it. What the operator needs is an interface that has been designed and tested to get that particular job done.
One argument seems most telling against the notion that good design is subjective. Research findings show no relationship between users' subjective ratings of a product and their objectively measured performance in using it.
- Tester: In software and system testing, the tester is
normally a person who (among other things) sits in front of the
computer to use the product. The tester knows what's being tested
forand actively looks for problems in the product. In beta
testing, the tester is usually the end user. In usability
testing, however, the tester is someone else altogether. Think
about it: Who designs and plans the usability test, facilitates
its conduct, collects the data and analyzes the results, devises
recommendations for design changes, and writes the test report?
It's not the user, but the usability engineer.
Usability testing does not want the user to focus on cataloging perceived defects but on performing the tasks. The user's participation in the testing allows the usability engineer to learn about how well the product is likely to support real users in doing the work that it's designed to support. Although users will, of course, be asked for feedback, in most cases usability testing is concerned at least as much with performance as with satisfaction (if not considerably more). We want the performance to be as natural and realistic as possible, so we want the users thinking about the tasks and not unduly about the interface.
When we conduct a usability test, we are the tester.
- Testing: This term is often misused as a synonym for
the larger field of evaluation or verification. You may hear
people say that they've "tested" their user interface
when what they've done is demonstrate it to users or test the
code that implements it. Testing, however, is only one method of
evaluation, in usability as in other engineering disciplines.
Software and system engineering, for example, define nontest
methods such as analysis, simulation, inspection/examination, and
demonstration. (Heuristic evaluation is a type of inspection, as
Just as in other disciplines, testing in usability is empirical, relying on observations and sometimes measurements. Usability testing observes representative users as they employ the product in performing realistic tasks. It may aim to find usability problems so that they can be fixed, or to verify that the product meets its usability requirements or goals. Usability testing includes measurement of user task performance, observation of user behavior and identification of problems, or assessment of user satisfactionor all of the above.
We do not claim that testing is necessarily better than other forms of usability evaluation; in fact, we believe that usability testing and usability inspection complement each other because they tend to find different kinds of problems. What we insist is that if you haven't subjected your product to an empirical method in which you observe users using the product to perform typical tasks, you haven't tested its usability.
Let us say this outright: There is no such thing as just semantics.
"But all this is just semantics!" we hear you cry.
Let us say this outright: There is no such thing as just semantics. Semantics is all about the very meanings of the words we use, the intention with which we use them, and the understanding they create in our audience. In communication, nothing is more important than semantics.
Language shapes reality. It sets up for us the reassuring feeling that realityor at least the small part of it that we're responsible forcan be comprehended in the way we intend. This is especially relevant to that small part of reality that belongs to usability, because its contributors come from diverse backgrounds and greatly need a shared terminology where meanings are controlled more rigorously than in general vocabulary.
We've looked at eight terms that are in frequent use in usability engineering or user interface design and development; and we have seen how, unless we use them with great care, they can create a reality that is different from the one we intend. To give our usability efforts a reality that is effective, efficient, and satisfyingparticularly when talking to nonspecialistswe need to use our terminology carefully.
Bruce G. Allen
Technical Systems Centre
280 Hunt Club
P.O. Box 9825 Stn T
Ottawa, ON K1G 6R3
Senior Principal Engineer
Computer Sciences Corporation
15245 Shady Grove Road
Rockville, MD 20850
Whiteboard Column Editor
Senior Principal Engineer
Computer Sciences Corporation
15245 Shady Grove Road
Rockville, MD 20850
Bruce Allen is an electronics technologist with Nav Canada in Ottawa, Ontario. A slothful and difficult personality, Bruce spends about half his time whining to his manager about spending half his time whining to software types who seem never to have heard of users or hardware. In his spare time Bruce stands in the cold and dark taking photographs where there's no light, or whines about mopping up after stirring brown powder into fruit juice in the hope of transmogrifying it into wine.
Elizabeth Buie is a usability specialist with Computer Sciences Corporation in Rockville, Maryland. A cranky and contentious personality, Elizabeth has griped about usability and HCI design since 1977, on projects from spacecraft control to mobile phone service provisioning. These days she focuses on Web sites and applications for the U.S. Government. In her spare time Elizabeth sits at one keyboard seeking to commune with the alto part in the choir's upcoming pieces, or at the other one seeking to grok the digital images that are mere shadows of her photographs.
Elizabeth's griping about usability and its language managed to convince Bruce, long linguistically disgruntled himself and ever ready to add another subject to his own whining. This article is their first effort to whine and gripe as a team.
©2002 ACM 1072-5220/02/0300 $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 © 2002 ACM, Inc.