Task-Centered User Interface Design
A Practical Introduction
by Clayton Lewis and John Rieman
Copyright ©1993, 1994: Please see the "shareware notice" at the front of the book.
Contents | Foreword | ProcessUsers&Tasks | Design | Inspections | User-testing | Tools | Documentation |

7.1 Manuals
        7.1.1 The Detailed Task Instructions
        7.1.2 The Command Reference
        7.1.3 The Super Index
7.2 On-Line Help
7.3 Training
7.4 Customer-Support Phone Lines


7.1.3 The Super Index


In the mid 1980s, a group of researchers at Bell Communications Research (Bellcore) noticed that it seemed almost impossible to choose the "right" names for commands. A system feature that one user called Copy, another wanted to call Move, while the designer thought it should be called Paste. This came to be known as the VOCABULARY PROBLEM. To determine how serious the problem was, the Bellcore researchers surveyed several groups of people, hundreds of individuals, asking for the names of common household objects and computer procedures. The results were very disheartening in those days of command-line interfaces.


The surveys showed that a computer system designer's first choice for a word to describe a system feature -- the "armchair design" for a command name -- had roughly one chance in ten of matching the word first assigned to the same feature by a randomly selected user. If the designer called the feature Paste, then nine out of ten users would expect it to be called something else. (G.W. Furnas, T.K. Landauer, L.M. Gomez, and S.T. Dumais. "The vocabulary problem in human-system communication," Communications of the ACM, 30 (Nov. 1987), 964-971.)


But the problem was worse than a simple indictment of armchair design. Even if the word most commonly selected by users was assigned to the system feature, there would still only be about one chance in five that a randomly chosen user would select that word. The survey of names for common objects showed that this wasn't simply a problem related to the newness of computer technology. People just didn't use the same words for things, although of course they would recognize other people's words.


Quite simply, the basic result meant that there was no "right" name for a command. Whatever word was chosen, 80 percent of the users would probably expect the command to have some other name.


Graphical user interfaces have partially overcome the vocabulary problem by asking users to RECOGNIZE commands in menus, rather than RECALL them and type them in. A user who expects a Copy menu item can usually recognize that the Move menu item has the same effect, although more complex concepts still cause problems. Within a manual, however, the vocabulary problem remains very real. A common complaint about manuals is, "I can't find anything in them."


We saw an example of this recently while watching some workers in their normal office setting. Two users were trying to find a word processor's "overstrike" feature, which they wanted to use to mark a block of text in a document. They checked all the menus, looked in the manual, and even looked in a third-party manual. They couldn't find the entry for "overstrike" in the index or table of contents of either manual, although they were convinced they had seen the feature somewhere in the program. Finally they gave up and decided to make do with a feature that forced them to backspace and overstrike each character individually. The feature they were looking for but never found was indeed available. It could be found in a dialog box under the font menu, and it was listed in the index. It was called "strikethru."


As this example illustrates, the vocabulary problem can seriously reduce a manual's usefulness. The typical manual's index has very few entry points to each concept or command. There will be the item itself, possibly listed hierarchically under some broader heading (such as Copy under Edit). And there will be a few "see" or "see also" references that point to the same concept ("Clipboard, see also Copy"). But there won't be entries for synonyms unless those synonyms have actually been used in the text. That means that the user who is looking under "Move" may never find the section on "Copy."


The Super Index helps overcome the vocabulary problem for manuals. This index makes use of a further finding of the Bellcore researchers. A single term is clearly inadequate as an entry point into the manual, but several well chosen terms can significantly increase the effectiveness of the index.


The first step in creating the Super Index, then, is to apply one of the techniques of task-centered design: borrowing. Look at other packages in the market you're entering and determine what terms they use for various operations. You should already be using the most common of those terms as command names in your own system. Add the other terms into the index as "see" references: "Paste, see Copy" For terms that have other meanings within your system, use see also: "Move, 24, 67, 92;, see also Copy."


For larger manuals it's worth taking a second step toward creating a Super Index. Survey potential users to determine what terms they would use for system features. The survey should describe each feature without giving its name (for example, "what do you call it when text is taken away from one place and put back in another?"). Ask users to give three to six synonyms for each operation. The number of users surveyed doesn't have to be large; even a half a dozen will make a big difference, but a larger number will be better. The five to ten most common synonyms for each system feature should be added to the index as "see" or "see also" references. The results of a small experiment done by the Bellcore researchers suggested that an index based on a small user survey might make as much as a four-fold improvement in the ability of other users to find items in the manual.




Copyright © 1993,1994 Lewis & Rieman
Contents | Foreword | ProcessUsers&Tasks | Design | Inspections | User-testing | Tools | Documentation |