By Scott Berkun, Nov 1999

“A foolish consistency is the hobgoblin of little minds” – Emerson

People don’t like to learn things. If they take the time to learn something, they expect to be able to apply that knowledge in many places. It follows that good designers conserve the number of things users need to learn to get stuff done. The streets in American cities are good examples of conservation of knowledge. Anywhere in America, yield and stop signs look exactly the same. Traffic lights use red, yellow, and green to mean precisely the same things regardless of the street or city. Mailboxes on street corners use the same colors and icons, so they are clearly identifiable anywhere. It becomes difficult for people when their knowledge of things breaks down. A driver from a country with different street signs who visits America will make mistakes until they learn the new signs. Even subtle variances like the difference in speed of two different yellow traffic lights can cause American drivers to make mistakes.

The rules from the streets apply to web design and all forms of interface design. If an application names a piece of functionality “print,” users will expect the meaning of “print” to be the same throughout the application. On a Web site, if the user sees the Shopping Cart icon in the upper-right corner, they’ll expect to see it in the same place, with the same appearance, on every page on that Web site, if not on all of the Web sites they visit. Not only does consistency benefit the user, it also benefits the designers and developers. Once the “print” command has been named by the designer, the developer doesn’t have to spend any more time thinking about how to name it. If there is code for their print command, it can be reused anywhere inside the application. Consistency is wonderful when used appropriately because it improves the experience for both developers and their users.

When Is Consistency Bad?

In rare cases, consistency can become a self-perpetuating monster: It has to be used for a purpose. A foolish consistency is one that serves no benefit for the end user. Making things look and work the same is pointless if the user can no longer accomplish their tasks. Rank making things useful above making them consistent. An example is interfaces for video games. Imagine your company was developing two video games, a driving game and a Pac-Man game. The best UI for the driving game would be a steering wheel, but the Pac-Man game would work better with a joystick and some buttons. Trying to design one UI to use for both of these games would be a disaster. At best you’d reach a middle ground that wasn’t good at anything. Consistency applied to certain user tasks can make the user experience worse, not better. Consistency does not guarantee usability. It generally helps a user interface, but there are no guarantees in interface design. In this video game example you would have to choose between the user’s cost of learning two different specialized UIs against learning one UI they could reapply but wasn’t well suited to any of the tasks they wanted to do.

In the traffic-light example, the timing of the yellow light in a four-way intersection might be changed by engineers to compensate for the specific traffic patterns of an intersection. A longer yellow light in one direction may give the busier road more time to get cars through than the other road with less traffic. It is a trade-off of a local optimization instead of a global simplification. Fixing a severe local problem may be worth creating a minor global problem. Having good data about how things are used, like the traffic data for the intersection, is the key to making these decisions. You have to be clear about the pros and cons of each end of the trade-off, and make the best decisions for the feature in relation to the entire product. Sometimes global consistency is the right choice. Sometimes the best thing is to optimize locally.

When Is Consistency Good on the Web?

Consistency is great because people like predictable things. They will feel comfortable when they can rely on different parts of your product to do exactly what they think it will do. A common Web site design mistake is taking an existing UI element from HTML and optimizing it for one Web site. An example is the drop-down list box provided by HTML for picking from a list of choices. The standard behavior is that the user has to pick an item from the list, and then click an OK button to confirm the choice. Some Web sites use Javascript to make the drop-down automatically confirm the choice, saving the user the extra click of hitting OK . Independent of all other things, this design might work well. But because this modified control looks similar to the default one used on the web, Windows and Macintosh users never know what to expect and are likely to make errors. The lesson here is that if a modification to a normally consistent control causes relearning costs and errors, it’s probably not worth it, especially if it’s only saving the user a single click. The Web is a bad place for optimizations like this because we know users visit many Web sites during a session, and most of them won’t have your new design.

I’ve had discussions with Web site designers who feel consistency is a thing of the past, and that Web site design is a new frontier where consistency matters less. It’s tenuous logic. The way human beings interact with the world doesn’t change when the technology does it will always be based on seeing, touching, and hearing things, and using our brains to interpret what those things mean. Human beings will naturally tend to reapply learned knowledge, and good designers will use this to make better designs. Creativity is great if the result is something more worthwhile or useful for usersóbut if the only result is that designers/developers are happier with their portfolios, then they are designing for themselves, not for their users.

The key issue is whether a specific application of consistency is useful and not foolish. When I think about interfaces on the Web, I think back to the early days of GUI interfaces. One of the best features of the Windows and Macintosh operating systems was the use of a standard menu bar for all applications. It may have reduced some of the creativity of applications in the ways they presented commands, but it made the lives of developers and users much easier because they could reuse things they had already learned. In this case, the global win of a consistent way to present commands to users outweighed any possible value of one application doing something wonderful, but was not shared by other applications. It is always a tradeoff, and this means that designers always have to consider the effects of the pursuit of consistency.

The Bottom Line: Rules of Thumb for Consistency

Here are some guidelines for thinking about consistency in user interfaces:

• Begin by reusing existing controls or concepts in your sketches and prototypes unless your goals include changing a specific user task or behavior, start with as much consistency as you can. Reuse of working concepts is good. Style guides are of great value here in helping you to reuse as much existing knowledge and good design work as possible.
• If your sketches and prototypes aren’t working in user studies or other evaluations because of the failure of existing concepts, try to grow an existing concept to cover the new situation you have. If you change the behavior of a control, apply that change everywhere the control is used. If you change a concept, consistently apply that change.
• If you can’t extend what you have to solve the problem, go and design a new widget or concept to solve your problem.
• If you have to use special cases (local optimization of a widget that isn’t used everywhere), make sure it’s the best trade-off you have.
• Always ensure that user success at tasks takes precedence over abstract design consistency.

These guidelines should help you to be as consistent as possible, without being foolish. It should also help keep your interfaces simple. At the heart of any design thinking is a series of trade-offs: speed versus reliability, ease of learning versus expert proficiency, global consistency versus local optimization. As Ron Fein once said, “Design is choosing how you will fail,” meaning optimizing for one thing always means failing at another. The key to good design is knowing which characteristics of your Web site or product are the most important, and which ones you are willing to give in on. If you are clear on the goals, success will always come from planning enough time in your schedule to think through the trade-offs of a wide set of alternatives. Consistency is a potential means for success, but not success itself.