Inconsistent Terms: A Sign of Amateurish Software

By Jeff Johnson

One of the worst mistakes one can make when developing a computer-based product is to be haphazard and inconsistent about what terms are used for what concepts. Unfortunately, this mistake is also one of the most common, because many software development organisations make no effort whatsoever to assure consistent terminology.

Unfortunately, the usual reaction from programmers is “So what? We have more important problems to worry about than whether we use the exact same term from one window to the next.”

There are two different ways for terminology to be inconsistent, and product developers often stumble across least one of them.

Different terms for the same concept

The first way to be inconsistent is to use multiple terms for a single concept. For example, a program might refer to “results” in one window and “output” in another, even though the same thing is meant in both cases.

When different words are used in different contexts to describe the same thing, users may not realise that the same thing is being described. Users are thinking mainly about their work. They don’t pay much attention to the software’s controls and instructions. Tiny changes in wording can cause a user to fail to recognise a known concept.

In reviewing software for clients, I have found the terms in each of the following sets being used interchangeably for a single concept.

• properties, attributes, parameters, settings, resources

• version, revision

• find, search, query, inquiry

• Exit, Quit

• Password, ID code, PIN number

• Stock Symbol, Instrument ID, Instrument, Instr Id

Inconsistent terminology forces users to keep thinking about the software—trying to decide whether two words mean the same thing or not. Well-designed software, in contrast, recedes into the background by letting users fall into use-habits and unconscious activity, thereby allowing them to focus their conscious minds on their work.

The same term for different concepts

Almost as common as using more than one term for a single concept is the opposite error: using a single term for more than one concept.

Many words used in everyday conversation have multiple meanings. People determine the intended meaning of a term either from the context in which it is used or by asking the speaker to clarify. Human-computer communication is less forgiving of ambiguity. It seldom provides conversational context as rich as that provided by human-human communication, such as redundant cues about the meaning of terms. People cannot ask the computer to clarify what it meant by a particular term. Therefore, sloppy terminology is less acceptable in software than in communication between people.

Keeping terminology consistent

In general, the terminology used in a software application to describe actions on objects should be extremely consistent. To maximise learnability and usability, terms used in software should map 1:1 to concepts in the software. Even if a term has more than one meaning in the external world (since the use of ambiguous terms in software is sometimes unavoidable), it should mean one and only one thing in the software. Otherwise, users often have to stop and think about which of the possible meanings is intended in the current situation.

Devise a product lexicon to help achieve consistent terminology

Very early in the product design process, a development team should specify clearly what concepts the software will expose to users, and what each concept will be called. One result of this is a product vocabulary or lexicon. It lists the names and definitions for every concept that will be visible to users in the product and its documentation. It also should not assign a single term to different concepts.

In order to assure that a product lexicon is devised and followed, someone on the development team should “own” it, probably the head technical writer assigned to the project. Once the product lexicon has been developed, it should be followed consistently throughout the software and its documentation and marketing literature. The lexicon owner is responsible for reminding the team to either stick to the agreed-upon term for a concept or to explicitly change it.

Use industry-standard terms for common concepts

When developing a product lexicon, a development team should keep in mind that certain concepts in graphical user interfaces have standard names. The names are the GUI equivalents of “reserved words” in programming languages. Designers, developers, and technical writers who rename such concepts, or who assign new meanings to the standard names, run a high risk of confusing users. Standard terms and their definitions are included in the various industry-standard style-guides, such as the ones for Windows, Macintosh and CDE/Motif. Software designers should know the industry-standard GUI vocabulary for their target platforms before inventing their own terms.

Use message files. Don’t embed labels and messages in the code

Both variations of this blooper—different terms for the same concept, and the same term for different concepts—are sometimes the result of developers simply failing to spot the conflicting use of terms. If the only way for a person to review a program’s messages, labels, and instructions is by operating the program or by searching through its source code, such oversights are likely.

On the other hand, if the text displayed by a program is all together in one file, reviewing it and checking it for conflicts and inconsistencies is much simpler. That is exactly what I recommend to all my clients: use message files.

When different parts of the software need to refer to the same concept or present the same message, they simply refer to the same text-string in the message file. That reduces the chances of committing variation A of the blooper: different terms for the same concept.

Duplicate strings in the message file should also be checked to make sure they don’t correspond to the opposite problem: the same term used for different concepts.

(Jeff Johnson is a Consultant at UI Wizards, Inc., a product usability consulting firm (www.uiwizards.com). He has worked in the field of Human-Computer Interaction since 1978 as a user-interface designer and implementer, manager, usability tester, and researcher. He has published numerous articles and book chapters on a variety of topics in Human-Computer Interaction and the impact of technology on society. He frequently gives talks and tutorials at conferences and companies on usability and user-interface design. He is the author of a recent book, GUI Bloopers: Don'ts and Dos for Software Developers and Web Designers (www.gui-bloopers.com). He is writing a book about common Web design mistakes.)

STC India | Home | Contact Us

Copyright © 2002 India Chapter STC. All rights reserved.