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?
- Who writes these rules, anyhow?
- What's in a standard?
- Why are they a mixed curse?
- So, should one be using standards at all?
- OK, then how does one use them?
- Where can one find more information?
- Why am I qualified to write about this?
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.
Lots of people. (Lots of organizations, mostly.) Standards and guidelines come in many flavors (the following with examples):
- International — standards developed by organizations to reflect agreements among national member organizations
- National — standards developed by organizations to reflect agreements among companies and other entities within a country
- Military and other government (e.g., DoD, MIL, NASA) (details to be added later)
- Commerce and industry — style guides for the look and feel of products to run on a specific platform
- Independent — guidelines developed by a company or person,
either to use along with their own consulting services or to sell in
book or electronic form
- ISO and ANSI Standards for Computer Products: A Guide to Implementation and Compliance, by Wanda Smith
- Principles and Guidelines in Software User Interface Design, by Deborah Mayhew
- Human-Computer Interface Design Guidelines, by C. Marlin Brown
- Project — a standard for a specific project, tailored from other sources
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):
- Rationale and principles. Why this recommendation is good design practice. Sometimes this includes the empirical human factors research on which the recommendation is based.
- Examples. How the recommendation might be implemented, sometimes in more than one way.
- Exceptions. Situations and conditions in which the recommendation might not apply.
- References. Sources of additional information about individual recommendations or about the topic of the standard as a whole.
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.
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.
- What if you needed a Web browser, and your vendor had used a data base application standard that called for every action to be confirmed by the user before being carried out?
- What if you commissioned an air-traffic control center (a safety-critical application if ever there was one), and your contractor used a standard aimed at office applications (which assumes that most errors are recoverable)?
- What if you had commissioned a custom application for your business and your vendor used the right standard but didn't have a usability engineering process, so the strong teamwork among your employees was never discovered and the product doesn't have any interaction to support that -- and now you've got workflow bottlenecks where you had none before?
- What if you were buying an office suite for Macintosh, and your vendor had based the design on a Windows standard? (Well, OK, this one can be handled by specifying which platform standard to use -- but I just had to get it in. Look at that travesty called Word 6.)
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
- Design considerations for any specific user population and the work they need to perform (unless they were written for those users/tasks/environment, as are a few highly specific military and government standards)
- Issues and constraints imposed by the context of work
- The content and structure of the information exchange that the HCI must support
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:
- Standards tend to prescribe features of the product --
- what the interface should look like
- how objects should be aligned on the screen
- what colors not to use together
- etc., etc., etc.
- You need something else to cover the hard part -- a usability process
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.
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.
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.
- 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.
- 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.
- Apply the recommendations. Refer to them when making HCI design decisions. (Caution: This is not as easy as it might sound.)
- 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.)
- 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.
Lots of places:
- Offices of ISO and the various national bodies
- The standards column ointhe SIGCHI Bulletin of the Association for Computing Machinery (ACM)
- The Usenet newsgroup comp.human-factors
- And, of course, all the webspaces I listed in the above discussion of who writes 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 am 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
Contact me for more information or to ask about usage permission.
Last updated 30 April 2006, to redo the visual design