Contents

by Elizabeth Buie (copyright notice)

So you're on a new software project and it's your job to design the user interface. Ah well, you'll just get the Windows Style Guide and take it from there.

Not so fast.

There's a lot more than that to using standards and guidelines for human-computer interaction (HCI) design. These guides are a mixed blessing, and could even be a mixed curse. Here are a few things it might help you to know.

Why do we need HCI standards?

Why do we want to use HCI standards in the first place?

The obvious answer (surprise!) is to standardize the look and feel of a user interface. We certainly want to standardize the various windows and dialog boxes of a single product, and we may also want to standardize the interfaces of multiple products or systems that people may be using. In addition, we may want to standardize to some extent across all products for a single platform such as Macintosh, Windows, or Motif. Standardization facilitates learning and reduces errors by taking advantage of knowledge the users have gained from other products or from other parts of your product.

There are a few less obvious answers as well to this question of what HCI standards are good for:

Incorporate human factors research and "best practice" in HCI. There is a large body of empirical research on the usability of specific HCI design features, and many recommendations have emerged from these findings and been incorporated into standards documents. Some of these are based on human physical characteristics, especially vision. Most are based on cognitive characteristics — how people process information — perceiving, thinking, learning, understanding, decisionmaking, etc. A few recommendations are based on affective characteristics — how people feel and react — preferences, excitement/entertainment, æsthetics, etc. See the sidebar to this article for examples of recommendations based on these three types of factors.

Smooth the HCI design process. Reduce the number of look-and-feel decisions that have to be made during design. The more guidance you can get, the less work it will be for you to do the design. And truly, you don't feel like arguing over whether your menus should be arranged logically or alphabetically, do you?

Achieve mandated compliance. Some countries have passed legislation stipulating that software products comply with certain HCI standards. Many US government contracts include requirements that the delivered system and/or product(s) comply with specific standards (usually US government standards or commercial standards). In these cases, you absolutely have to use the specified standard(s) and make sure your product complies.

Who writes these rules, anyhow, and what kinds of standards are there?

Lots of people. (Lots of organizations, mostly.) Standards and guidelines come in many flavors (the following with examples):

What's in a standard?

HCI standards always include statements about the features of the product's HCI design (with one exception, which we'll come to later). These statements may be requirements (the HCI shall have some feature if it is to comply with the standard) or recommendations (the HCI should have some feature). In most cases, most or all of the statements are recommendations, because the standard is trying to be general enough to cover a wide variety of applications, and there are very few design features that are always needed. HCI standardization is not like, say, telecommunications standardization, because the appropriate features of a UI often depend on who the users are, what they're doing, and in what environment they're doing it.

From now on, I'm going to talk about "standards." When I do, you should think "standards, style guides, and guidelines books" -- whichever kind of document you're using. I'm also going to talk about "recommendations" because that's what most of the statements in the standards are. You just think "requirements, recommendations, guidelines, and design rules" -- whatever applies to the standard you're working with.

In addition to the recommendations, a standard typically includes one or more of the following kinds of information (usually for each recommendation):

Finally, some standards (particularly those of international, national, or military/government organizations) include a Compliance section. This prescribes the method to be used to establish that the product complies with the standard.

There is one exception to the declaration that standards always include statements about product features, and that is standards for the HCI engineering process. But these are few and far between (I know of only two, and they're not in final form yet), and they're not really the topic of this discourse. They aren't the problem.

Why are HCI standards a mixed curse?

Two reasons. First, too many projects rely on them to cover too many of their HCI design decisions. This doesn't work. According to Jared Spool, founding principal of the usability consulting firm User Interface Engineering, standards and guidelines address less than 10% of the questions that arise during user interface design.

Second (and more dangerous), test houses are starting to use standards as a means of certifying usability. They'll evaluate your product, and if it complies with a selected standard, poof! it's usable. You get a certificate, which you can use to assure potential customers that your product will meet their usability needs. Or if you're an employer buying or building software, you can use it to get the government's occupational safety folks off your back.

Sound good? Think again.

There's one tiiiiiny (or teenincey, as we used to say where I grew up) little thing that HCI standards and guidelines cannot do: ensure a usable product. In particular, they cannot address

In short, standards just can't cover the hard part of HCI design.

Durn it, why not?

OK, fair enough. There are two reasons why not -- which just happen to be closely related:

Now wait just a minute, you object — there are standards for the process. You know there are.

You're right, there are -- or are about to be, in any case. In particular, ISO 13407, User-centred design of interactive systems, is in preparation and should be available soon. In addition, ISO 9241-11, Ergonomic requirements for office work with visual display terminals - Part 11: Guidance on usability, gives some advice on specifying and measuring usability. But these are extremely general and must be tailored to each organization's needs. Without a usability process for your project, even an HCI process standard cannot guarantee you a good interface.

So, should one be using standards at all?

Yes, absolutely. (See the first topic we discussed, "Why do we need HCI standards?") Just keep them in perspective. Don't rely on them for all (or even most) of your design decisions; and don't let your standards compliance lull you into complacency, thinking that you have thus assured yourself of a product that meets the needs of your users, their tasks, and their work environment.

OK, then how does one use standards?

There are three reasons I'm not going to give a detailed description of the HCI engineering process on this page: There isn't space; many of the details depend on the project in any case; and (the real reason, if you must know) I just don't feel like it right now. So I'll just give a brief outline here. Maybe I'll write another page about the process later.

  1. Select which of the available standard(s) you are going to use as your starting point. This is probably the easiest thing you have to do.
  2. Develop a project standard by tailoring the standard(s) you selected to use. Identify the specific recommendations that apply to your project and determine how you are going to apply them.
  3. Apply the recommendations. Refer to them when making HCI design decisions. (Caution: This is not as easy as it might sound.)
  4. Revise and refine your project standard as necessary to accommodate new information and considerations that may arise during product development. (Note: Revision may occur at any stage after the original development of the project standard.)
  5. Inspect the design and the completed product to verify that your HCI actually complies with the project standard.

Caution: The above steps do not cover the entire usability engineering process. They address only the use of HCI standards.

Where can one find more information on HCI standards?

Lots of places:

Why am I qualified to write about HCI Standards?

In the HCI field since 1982, I've been a member since 1992 of the Human Factors and Ergonomics Society's HCI Standards Committee. This committee has contributed to various ISO HCI standards (especially 9241) and is currently writing the standard HFES-200, Ergonomics of Software User Interfaces, as an ANSI-accredited standards developing organization. I was the editor of the sections on definitions and references. For more information on HFES-200, contact HFES.

This article was published in the March/April 1999 issue of <interactions>, the bimonthly magazine of ACM/SIGCHI. Copyright © 1997, 1998, Elizabeth Buie. All rights reserved. Permission is granted to print this page or link to it, as long as such use is personal or educational and is not for commercial gain or profit. This article may not be republished or redistributed without permission.
Contact me for more information or to ask about usage permission.

n = navigation bar. t = top of page.