No design standard can ever specify a complete user interface. Thus, by definition, much design work remains, even if the designer is committed to complying with the appropriate standards. Often, the most important design elements are those that cannot be specified by a standard, since the standard cannot know the specifics of the individual domain addressed by the design.

For example, I was recently involved in the design of an e-commerce site. The draft home page had three ways of getting to the products: search and two navigation schemes, both of which were presented as simple lists of choices. One navigation scheme was structured according to the way most users think about the domain; the other scheme was structured according to the way many of the manufacturer's own staff thought about their product lines. Results from usability testing:

  • success rate of 80% when people used the navigation scheme structured according to most users' mental model
  • success rate of 9% when people used the navigation scheme structured according to the company's internal thinking

Conclusion: the second navigation scheme was dropped from the design, even though this pained some of the project members. The second scheme had its advantages for those people who used it correctly, but it led most users into trouble, so it did more harm than good.

I mention this result for two reasons: First, even though both navigation designs looked identical and followed the same interface standard in terms of appearance, layout, and interaction techniques, their usability was drastically different. The first design was almost nine times better than the second. This difference sums to big dollars for an e-commerce site that will sell nothing unless users can find the products. The difference in usability was not due to differences in surface design but to differences in deep design: finding out how to best match a Web design to the users' needs and how to best structure the information architecture. Thus, even when sticking to a design standard, there was plenty to do for the site designers. A bad designer would have used the bad navigation scheme on the home page and never tested it.

Second, the result also shows that great usability is not guaranteed even when following a detailed design standard to the letter. A standard ensures that your users can understand the individual interface elements in your design and that they know where to look for what features. It does not ensure that users will know how to combine the interface features or that the system will have the features users needs.

Eric Davis, an Information Architect with Resource Marketing, recently reported on a usability test of shopping cart terminology. The draft design featured the term "Shopping Sled" since the site (selling winter sports products) had a desire to stand out and avoid standard terminology. Result: "50% of users did not understand The Sled concept. The other 50% said that they figured out what it meant because it was in the same location as a cart would be. They knew that you had to add to something, and the only something that made any kind of sense was the Sled." Lesson: Do not try to be smart and use new terms when we have good words available that users already know.

Of course, there is no guarantee that a site that uses the term "shopping cart" will have a shopping interface that is easy to use. All that is ensured is that users will understand the term when they see it used as a link around the site. But that's a usability benefit well worth taking.

Jakob's Law of the Web User Experience: Users spend most of their time on other sites. Thus, anything that is a convention and used on the majority of other sites will be burned into the users' brains and you can only deviate from it on pain of major usability problems.

Since the dawn of time (1984), we have known that consistency is one of the strongest contributors to usability. The Macintosh was based on a detailed book of Apple Human Interface Guidelines that were followed by almost all applications. One of the main benefits of the Mac (and later Windows) over earlier systems was the resulting consistency that made it possible for users to use software right out of the box. For example, people knew that you could move stuff around by a sequence of (1) select-object, (2) Cut-command, (3) scroll-to-new-location, (4) click-on-insertion-spot, (5) Paste-command. Always the same sequence. And the Cut and Paste commands were always in the Edit menu and were always abbreviated Command-X and Command-V. No real reason people should associate the letter V with insertion or pasting, but since it was always the same, it worked.

Despite the strong consistency in all Mac software do you think Excel looks like MacWrite? Or that there was no design creativity involved in making MORE (a popular outliner)? It's clearly not the case that all GUI software is the same even though most software has pretty strong compliance with the platform design standards these days.

Similarly for the Web: following design standards simply ensures that users know what you are talking about. It's like using standard English words rather than your own vocabulary when writing. You are still the one who decides what story to tell and how to put the design elements together.

Rules for Design Standards

To be successful, an interface design standard must:

  • be well-illustrated with examples since designers go by the examples much more than body text
  • make sure that the examples fully comply with the standard in all aspects and not just the one they are intended to illustrate (designers may pick up more than one hint from a given example)
  • have extensive and comprehensive checklists as much as possible (designers prefer to scan down a list instead of having to read text) — for example, a list of all elements that must be on every page or a list of preferred terminology
  • have a standards expert available both to review new designs in a formal standards inspections and for more informal consultations whenever designers are in doubt about the correct interpretation of the standard (if there is no easy place to turn with questions, then each designer will make up his or her own answer — guaranteed to be different in each case)
  • be supported by an active evangelism program. It is not enough to wait to be consulted: you must actively seek out projects and visit them to tell them about the standard and to (gently) comment on their designs and how to correct the inevitable deviations
  • be a living document under the control of a standards manager who updates the standard as new issues emerge
  • either comply with the most popular other design standards or contain explicit statements highlighting the differences to these other standards
  • be supported by development tools and templates that make it easier to comply with the standard than to implement a non-standard design
  • have a good index (if printed) or a good search supplemented with hypertext links to related rules (if online)

Evangelism outreach is especially important for intranet standards since every department will have an inclination to ignore mandates from headquarters. They usually do so with the excuse that "we are different and the folks at HQ don't know our situation." True, but everybody is special so the total system will be utter chaos if people are allowed to diverge because of special circumstances. Usually, the greater good is indeed greater, and overall usability is increased by consistency. There can be a few cases where circumstances are so special that an inconsistency should be tolerated, but deviations must be limited to cases with a very, very good reason (most good reasons are not good enough).

Finally, realize that a standard has its own usability concerns. This is true whether the standard is implemented as an interactive website with hypertext links or whether it is a traditional printed document. Therefore a proposed design standard should be tested with designers to ensure that they can use it.