DESIGNING FOR USABILITY
Scott L. McGregor
ABSTRACT
There is more to designing a user interface than patching together various user interface elements. This paper postulates that the user interface should be designed to take advantage of the strengths of the "human machine" and avoid its weaknesses.
____________________________________________________________________________
Scott, L. McGregor
has been developing and managing software development for over 20 years, including ten years at Hewlett-Packard, where, as manager of an R&D team managing software development of commercial CASE systems, McGregor developed the initial concept proposal and prototypes for prescient agents described here. McGregor is the founder of Prescient Software Inc., where he continues his interest and work in Prescient Agents.McGregor welcomes contact from interested readers. He can be contacted at Prescient Software Inc., 1717B Marshall Ct., Los Altos, CA 94024 or by electronic mail at mcgregor@prescient.com.
INTRODUCTION
We have all seen those advertisements that claim that such and such product is now user friendly, because it is now in X or Motif . But of course, just using X does not automatically imply user-friendliness. You can build as abysmal an interface in Motif as you can with a command line. The success of an interface is not merely how good it looks, but how well it supports the human using it. Designing for usability then is not merely using this button or that menu. It involves developing a strong mental model of the conflicting cognitive demands on the user and looking at how you might reduce those demands, or augment human capabilities. In this article, I offer up such a model, along with some hints for how to apply it.
The most important thing to remember is that the Computer-Aided prefix in CAW, CAD, CAM, CASE, etc. means that the computer is supposed to aid the user, not vice versa. Many products fail because they treat the user only as a data entry clerk, to provide information and instructions to the computer, not as someone who has a job of their own to do.
A MODEL OF THE HUMAN MACHINE
The human brain, the human sensory system and the human motor system are parts of the human machine (see Figure 1). Like all machines they do some things well and other things less well. Unfortunately, we ask these human machines to do many tasks for which they are not well suited. The primary tasks of designing for usability are:

FIGURE 1: A MODEL OF THE HUMAN MACHINE
Major aspects of the human machine are.
• Its ability to acquire information - perception,
• Its ability to retain information - short term and long term memory.
• Its ability to interchange information with others - communication.
• Its ability to operate on information - reasoning ability.
• Its ability to manipulate its physical world surrounding - motor actions.
Now, let's take a look at each of these areas, focusing on the major limitations of each subsystem, how it might be augmented, and what it is good at doing.
MEMORY
Major limitations of human memory are.
1) Information forgotten (or no longer retrievable on demand)
2) Information mis-remembered.
The major technique for augmenting short term human memory is to record data in the physical world where it can be retrieved quickly without the need for remembering. Typically this means writing it down and keeping the note in a visible place. In computer interfaces this is a typical function of menus and other pre-cached lists.
Example:
In the Unix command line, you have to remember and type the names of files that you want to operate on. In a desktop, such as Visix Looking Glass, DC[ Xdesktop, or HP's HPVUE, the names of files are displayed-you don't need to remember how to spell one, you just pick it. There's no possibility of a typographical error (and resulting file not found message) either.
The major technique for augmenting long term human memory is to record the data in the physical world and organizing it for later retrieval. Typically this means writing it down and putting it in a book or file. In computer interfaces this is a typical function of a file or database.
Example:
Many X applications take long lists of command line flags that control foreground and background colors, size and position, fonts, etc. If the user has to remember these items each time they can become distracted from their task. Storing these preferences in an Xresources file allows the user to have them applied effortlessly. Systems that also allow real time alterations to their preferences, and then automatically update their stored flies (e.g. the Elm mail Program and the R5 editres) do even better.
The major advantage of the human memory processor is its ability to do associative retrieval on large amounts of unstructured information.
Example:
When searching for technical material, a reference librarian can often be very helpful. Exhaustive search strategies such as grep often retrieve too much unrelated material (such as all the articles on Crayfish, when you asked for articles on the topic "Cray". Or they find too few when using keyword searches when synonyms exist (looking for information on "deleting" files which is actually under "removing (rm)" files.) People's internal associative mechanisms can often find the desired material much more quickly.
COMMUNICATION
The major limitations of human communication are:
• Human communication is frequently imprecise.
• Humans often assume more has been intended than was actually stated.
• Humans often fail to communicate sufficient information.
• Humans often fail to communicate to enough parties.
The major techniques for improving human communications are:
Example:
Forms, fill-in-the-blanks items, checklists, and menus all restrict choice to a structured set of options. The choices provided are assumed to be exhaustive, and the meaning of the choices is more likely to be commonly interpreted. The purpose and meaning of a bug report form with filled-in blanks is likely to be better understood than an informal electronic mail message.
Example:
When someone sends you a request to attend a meeting, and you don't reply, there is likely to be confusion between you and the sender about whether you will be there. If you use a system such as the Coordinator that forces a reply such as a yes or no, there is less likely to be confusion.
Example:
When you do a grep on a symbol name in a program, You will only see the line that it appears on. Changing that line, without looking at nearby lines can lead to problems. Static analyzers that work with editors can position you in the file at the desired line, but let you see more lines of context above and below, helping you to avoid errors.
Example:
Electronic mail is good for sending information to people you know are interested, but not good for reaching those you don't know about. One of the valuable things about software such as News, and networks such as Usenet, are that they allow you to address all the people who are interested in (subscribe to) a particu.1ar topic. This avoids you needing to know all the' affected people before making a change, or knowing who to ask a technical question.
Major advantages of human communication forms are:
• Brevity. Communicating more than stated because contextual information is not explicit, but understood by both parties.
• Ambiguity. Humans can communicate somewhat about things that are only imprecisely understood, or for which common context is limited.
Example:
When AI professor Roger Shrank of Yale taught computers to read stories, he told it the story of someone who came into a restaurant, ordered a meal, paid the bill and left. When asked if the person ate the meal, the program did not know. The convention of paying for the meal only after you eat the meal was not explicitly stated for brevity, since readers would assume it. The Cyc project at MCC is attempting to codify many things in typical human common contexts-what we call common sense. And computers are still not regarded as capable of the artful use of ambiguity in poetry.
REASONING
Major limitations of human reasoning are:
Example:
People are good at choosing from a dinner menu, or following a recipe. But activities such as playing chess or solving a large system of linear equations can lead to big blunders.
Example:
This is a primary reason that robots are Preferred on many assembly lines. Key-punching requires extensive checking due to unavoidable human errors.
Exampl:
A frequently cited cause for pilot error, or control tower error is when there are too many things to remember, or too many conversations going on. pilot error occurs when writing software for the same reason. Programmers have been shown to make more errors as the number of people they must communicate with, or the number of modules that they must manage increases. Object-oriented programming is in part an attempt to limit the number of details the writer of an application or an object needs to know.
Example:
One reason that many people alias the remove file command (rm) to always ask before deleting (nn -i) is to avoid the common typing error.
Major advantages of human reasoning modes are:
Example:
When AI programs, such as Mycin (a medical expert system), are faced with data outside their information domain they often make radically wrong misdiagnoses. Doctors, while still not perfect, are more likely to recognize that a situation is outside their expertise and can then seek additional experts.
PERCEPTION
Major disadvantages of human perception are:
Example:
Because a symbolically linked file shows up in some directory listings, people may assume that the file is local when it is actually on a different disk or workstation.
Example:
Because hidden (dot) files are ignored in some commands (such as the usual form of directory list) people assume that a directory is empty when it is not.
Example:
Many people are confused when they try to access files that are NFS mounted when they are logged in as user root. On their own machine root is all powerful, but on other machines NFS reduces the authority of root, leading to frustrated expectations.
Example:
When directory lists get large, people no longer look carefully through them for files that are candidates for deleting. A commonly observed result is that as file systems get more and more full, users have more difficulty finding files to remove.
Major methods for augmenting human perception are:
Example:
To find out what files are in a directory, you could use the ls command in unix, but you might overlook hidden files. Using find as well might help you discover some "dot" files and help you learn more about the directory, and about defaults in the tools you used.
Example:
Since system administrators can't be on line and looking at all things at once, they collect log files that look for significant events they can't watch. Daemon processes, often fired by cron, can perform valuable instrumentation tasks as well.
Example:
High level languages can show more algorithm in a smaller space, and thus it is easier to grasp the significance of a page of high level code compared to its assembler equivalent.
Major advantages of human perception are
Example:
As most programmers have observed, it is possible to watch a program run and talk on the phone at the same time. When programming, errors can be reported to the user both visually and audibly.
PHYSICAL MANIPULATION AND MOTOR SKILLS
Major disadvantages of human physical manipulation capabilities are the limited strength, endurance, degree of freedom, speed and precision of human motor skills.
Major methods for augmenting human physical capabilities are through applications of simple machines (levers, pulleys, screws, inclined planes, etc.) assembled to provide increased leverage, endurance, mechanical degrees of freedom, speed and precision.
Major advantages of human motor control are human abilities to use perception and motor skills interactively to improve immediately and correct their current performance.
A DOZEN RULES OF THUMB
Don Norman has noted that perhaps the most important rule of thumb is that sometimes you should break the rules. This is certainly true in designing for usability, but nonetheless, there are some hints that sometimes can be helpful:
1. Small details matter greatly in their effect on usability. There are all kinds of nonlinear effects in usability, so pay close attention to detail.
Example:
If your only control feature is a pop-up menu bound to a mouse button, such as used in xtenn, people may not know the menu exists. If it is bound to a pull-down button at least there is a hint where to look and what to do. The choice of Pop-up vs. Pull-down menus seems like a small thing but it can make a world of difference to the first time user.
2. "Logically equivalent" and "mathematically equivalent" representations are not likely to be "cognitively" or "usability" equivalent. Also, it is not simply enough that two alternatives support the same desired capabilities, but they must also restrict the same undesired error possibilities, and place similar cognitive loads on the users in terms of memory and communication.
Example:
A command line (e.g. the rnb mail program) and a menu based solution (e.g.may both offer access to the same functionality, but it is possible to make a typographical error in the former that is not possible in the latter. Conversely, you can select the wrong action much easier in the menu system than in the command line version, and the menu may be slower for expert users.
3. When multiple people are expected to use a piece of software cooperatively, perceived benefits must balance or exceed perceived efforts, on each individual. A benefit to the group, from the efforts of an individual may not be sufficient to ensure regular performance by the individual if the individual's benefit is too indirect, infrequent or delayed.
Example:
Jonathan Grudin did a study of electronic shared calendar systems. He found that in many cases they failed. The reason was that everyone had to enter their calendars on line to have useful scheduling data, but only those few people who scheduled a lot of meetings got the benefits. The result was that over time these systems failed as the people using them found that they weren't working because their data was bad-because there was insufficient benefit to the people who rarely scheduled meetings.
4. Take advantage of people's natural skills of anticipation; allow type-ahead, mouse-ahead and think-ahead. Pre-cache results of anticipated actions, display status information before it is requested.
Example:
Some applications build certain user-interface elements on the fly, when the user first requests them, to speed application startup. But this introduces a delay when the element is first needed.instead, the application should use idle time to build these element. The Canon Cat word processor is another example. When you turn it on, it displays the view of the document last used immediately, so you get your bearings while the system continues to boot up. The system seems to turn on instantly when it really doesn't.
5. Do not lock the user from an action while another action is occurring. Let the user know what is happening, and how things are progressing for lengthy tasks-do not leave a static display (or wait cursor) that leaves the user wondering if something is dead or just slow.
Example:
An early version of a text formatter I once used would display a blocking dialog box whenever I made a mistake. in fact, it locked the whole display, so 1 couldn't even go to another application while 1 was waiting to find out how to fix things. On the other hand, xrn uses nonblocking dialog boxes that inform me of its actions but let me proceed to look at other screens.
6. Do not gratuitously entertain the user, but allow the user to enjoy themselves as they learn new things. Make sure they have a good experience with some aspect of the product within 5 minutes the very first time they use it. Assume they haven't read the manual, and haven't taken any class. Try for ongoing reinforcement as they learn more things at least every half an hour, more frequently in environments with frequent interruption.
Example:
If you use the SAS programming language and you start with their computer based training tool, or their introduction guide, you can learn enough to do interesting programming, database manipulation, graphics or statistics in just a few minutes-this hooks you into further learning. But if you start by looking at their reference manuals you'd probably give up. Unfortunately, too many programs provide only reference manuals.
7. Make internal data representations and implementation details hidden from the user, so the user focuses on the task instead. Think deeply about what the user is trying to do, what objects he is concerned with, and what actions he will want to do to those objects. See if there is a good mapping between those mental objects and actions and the representations and manipulators in the product.
Example:
In the early days of network programming, to access a file on another machine, you had to know which machine it was on, and you had to copy it to your machine using a tool such as ftp. Today, with file systems such as NFS, a file can be on another machine and accessed as the user as if it were local-no copy is needed. You don't even have to know the machine name if the remote filesystem is mounted by an administrator for you. The user view lets you be unaware of all the network complexity.
8. Do not fear treading new ground. You may find a representation or mapping that eliminates many current peripheral tasks and lets the user concentrate on the root tasks-thus simplifying work considerably. This may deviate somewhat from conventional ways of doing things. But if it simplifies the work enough it will become compelling enough to learn the new habits required. (E.g. Visicalc replaced previous matrix manipulation languages almost overnight). Too often people copy interface instead of thinking deeply and therefore they do not contribute as greatly as they might have. On the other hand, gratuitous variation may just inhibit learning and habit formation, so be sure you have a reason based on items above for your variation from convention.
Example:
As noted above, before systems like NFS were created, users were distracted by the need to remember which machines files were on, and how to access them. NFS simplified the view, eliminating these distractions, so users could concentrate on just using the file wherever it was. But to do this NFS had to be different from the previous standards like ftp and rcp.
9. Do not leave the user interface design to the end. User interfaces are not peanut butter that can be spread on thinly after everything else is done, because they won't stick. Instead, start with the user interface. Write the user manual next, or create a storyboard, screenplay or scenario first that shows what the product will do. Only then should you reason backward to find out on what underlying functionality must be created to base the product.
Example:
One of the limitations of xmb and xrn is that they came after the functionality was delivered. As a result, things not in the original functionality are not allowed. You can't see new mail in xmb until you do an "incorporate", and you can't see graphics in xrn, because rn only knows how to display text (compare this with the NEXT newsreader which does include graphics, because it was designed that way from the start).
10. Do not face the user with too many choices. This is a major failing in many new products today, that are easy to use once configured, but you already have to be an expert to configure them rationally. Do not attempt to make up for your ignorance of what the user wants by making the product customizable. Mostly, users want to be comfortable using the product straight out of the box. Talk to customers and find out what they like, or try anything and see how customers react. If you must ask the user to customize the system to their own needs, provide a usable default, and a working example, and then allow them to make only a few small refinements to the default, instead of asking them to define their solution from scratch.
Example:
One of the great benefits of X is that so many things are configurable. You just set them up in your.Xresources or.Xdefaults file. The curse is that you have to. Many programs take horrible default choices, and some just plain won't run until the configuration files are attended to. Systems such as the Elm mailer, also have many choices, but allows the set of choices seen by the user to be kept small until the user wants to see more. This way the user isn't intimidated. The defaults are well selected too, and many users never change a thing.
11. Be excellent to those who use the products you build. Talk with potential customers often and learn to anticipate how they approach problems, what knowledge and skills they already have. Learn the jargon and the models that are the basis of their discipline.
Example:
An early drawing package 1 once used forced me to draw lines and curves by giving cartesian coordinates and functions. Sure it was precise, but for doing freehand art work for diagrams it was terrible. An early font editor did not support "points" as a measure--only inches, centimeters and pixels-despite the fact that fonts have been measured in points for hundreds of years. In contrast, the Scribe text formatter was a real advance because Brian Reid, its creator talked both with document designers, and with people who wrote (but didn't format) documents. Scribe allowed the users to specify what they wanted without having to specify how to get it, which is what users had liked about using human secretaries to produce documents prior to using Scribe.
12. Stand on the shoulders of the giants who came before you. Read the historical literature, not simply the latest literature, but back to the 60s and 70s; Engelbart's NLS, Ivan Sutherland's SketchPad, Xerox PARC's work on Smalitalk and the Altos are still inspirational in the 90s.
Example:
PC systems and Macintosh systems are getting Virtual Memory only today, but it has been available on large machines for a couple of decades.
CONCLUSION
Applications developers and their management face large problems. Very few people have a background in all the relevant disciplines from Cognitive Psychology to Graphics Design to Computer Science. An article such as this one can never replace years of study in these areas. But it can be a helpful starting point for discussion for developers who are new to designing for usability. The models and hints in this article have proved useful in this way for me. 1 hope they prove useful to you as well.
BIBLIOGRAPHY
For those interested in pursuing these topics further, here are some sources that inspired this article:
Analysis of the human cognitive abilities from a machine perspective inspired by works of Herb Simon, and of Stuart Card, Thomas Moran and Allen Newell.
Goals of Augment Memory, Improve Communication, Enhance Reasoning are from joel Birnbaum (Hewlett Packard VP of R&D) lectures on "Domesticating the computer."
Electronic Structured Communication ideas are from Tom Malone ("Object Lens"), Terry Winograd, and Francisco Flores ("the Coordinator"). Underlying nonelectronic communication theory are from Speech Act linguistics of Wittgenstein, Austin and Searle.
Performance is best with fewest choices from "the principle of monotony" and "importance of habit formation" from "the Humane interface" lectures by Jef Raskin (designer of the Apple Macintosh Ul).
"Wide and shallow... narrow and deep" ideas from are Don Norman's "Psychology of Everyday Things."
Comments on anticipating actions are from my own research on Prescient Agents-see paper in this issue.
Lack of established context preventing perception is from james Burke ("The Day the Universe Changed"), Thomas Kuhn ("The Structure of Scientific Revolutions"), Irme Lakatos, ("Proofs and Refutations"), Ludwig Wittgenstein ("Tractatus Logico-Philosophicus").
The importance of information density and compact representation from Edward Tufte's "Envisioning Information" and "Quantitative Display of Information."
Perception/performance feedback loop model is from Douglas Engelbart, ("NLS" papers), Don Norman ("Psychology of Everyday Things" and "Cognitive Artifacts"), Ben Schneiderman ("User Interface Strategies" lectures).
Individual benefits vs. group benefit economies are from Jonathan Grudin (CSCWU88 Conference Proceedings).
Ensuring quick rewards to new users is a more restrictive version of Ted Nelson's 10 minute rule in "Computer Lit."
Cult film humor ("Be Excellent...") courtesy of "Bill and Ted's Excellent Adventure."
"On shoulders..." is from Isaac Newton.