Over the last 25 years nearly every company that I’ve worked for has issued the command to, “Make our products consistent!” This consistency decree is often accompanied by examples of toolbar icons, menu names, keyboard shortcuts, and user interface components that differ across multiple products developed by the same company. The decree has even more urgency when a company goes on an acquisition spree and buys new products and companies to bolster its competitive portfolio. Along with the consistency decree, there are often a few quotes from aggrieved customers who complain that inconsistency leads to errors, increased training, and reduced productivity. The goal of user interface consistency is laudable and often adds values, but it is often fraught with hidden complexity and risk. In fact, there are times when making things perfectly consistent is a major mistake.

What should you consider when your manager comes to your office and says that there is a new corporate initiative to make all the products consistent and puts you in a central role as “consistency czar”? The first question you might ask is “Consistent with what?” There are many types of consistency and you will have to decide which ones make sense to consider.

Jonathan Grudin wrote a classic article entitled “The Case Against User Interface Consistency”. The reference is:
Grudin, J. (1989). The case against user interface consistency. Communications of the ACM, 32, 10, 1164-1173. You can find the article online at: http://research.microsoft.com/research/coet/grudin/papers/cacm1989.pdf

Don’t let the date of the paper scare you off. This is a classic and it reaches beyond the details of the user interface to argue that there are many types of consistency. Grudin listed three general types of consistency in his paper:
• Internal consistency of a product (or product set). Here you are looking at consistency between user interface components like windows, pages, menus, dialog and message boxes, error messages, and help objects.
• External consistency of a product with other products and related style guides (including general, platform, and product family style guides). External consistency is important when the product you are working on shares something with other work or recreational products that people use.
• Metaphoric consistency of products with their real-world equivalents. Metaphor here can include properties, behaviors, and terminology associated with user interface components.

Each of these general categories of consistency can be broken down further into subcategories including:

• Visual consistency (icons, color, general layout of controls).
• Interaction and feedback consistency (similar methods of navigation, keyboard use, progress, error messages, mouse pointer cues, etc.).
• Consistency in physical characteristics of a product.
• Consistency in terminology, input/output formats, and text.
• Consistency with user and tasks characteristics.
• Consistency with user goals.

Perhaps the most important type of consistency (and least considered in many cases) is consistency with user goals and task demands.
When would you explicitly consider designing an inconsistent user interface in the same product or different products from the same company? One common inconsistency involves the two usability attributes of “efficiency” and “learnability”. A product that is designed for untrained and infrequent users would be quite different (and inconsistent in many ways) from a product that is used many times a day, like call center software. Similarly, tax programs designed for individuals in the USA who file their income tax once a year would be inconsistent with a tax program used by trained accountants who have to do hundreds of tax returns. The tax program for an individual might use a “wizard” architecture where the person steps through the tax preparation one small step at a time with detailed assistance on every screen. In contrast, a program designed for experienced accountants might present a single long form, devoid of help, where they can input tax data without the overhead of the step-by-step wizard. When designing a product, it is critical to consider user and task characteristics explicitly and make sure that your designs are consistent with user goals and not general recommendations like those you find in various operating system or general UI style guides.

Don’t blindly follow the guidelines of a general style guide in a misguided belief that you need to use the same type of interaction model in all your products. If your product is going to support two or more distinct groups of users and tasks, then you should design for consistency with user goals rather than consistency with a general operating system style. Your user interface design might be inconsistent in some ways, but consistent with the way different classes of users work (and guess which one will ultimately affect the success of your product?).

Consistency is an incredibly complex issue. The complexity of consistency becomes more apparent when you consider different levels of internal and external consistency. Internal consistency deals with a single product or product suite that you are developing; external consistency is focused on consistency of products that people use that are not under your control. For example, if you are working on a statistics tool, it is quite likely that your customers will want your product to be consistent with Microsoft ® Excel. Several years ago I tested the search features in a Web application and a common suggestion from participants was to “make it work like Google” because they used Google every day for both personal work queries. The problem here is that for your specific goals, making your product work like Excel or Google might be exactly the RIGHT thing or the WRONG thing to do. So, when you are given the task in your organization to make things consistent, you will often have to consider consistency at many levels – a very difficult task.

Whenever I have to fight that battle I’m comforted by Emerson’s observation that “a foolish consistency is the hobgoblin of little minds.” I like to think he was anticipating those in a hundred years who would point to Microsoft as an exemplar. Maybe not, but I feel better anyway.

Seriously, I think that patterns help to resolve the conflict between consistency and conceptual integrity. You don’t have to completely re-invent the wheel, but you can still stand on the shoulders of giants without becoming a slave to Redmond. It seems like the best reason to break from convention is in the presence of a clearly articulated deficiency in the accepted pattern. Or a well reasoned argument about why a unique solution is superior. Or superior enough…

One minor quibble I have with your argument is about form and function. Form often does follows function, but forms also inspire new functions, or even new forms. I think that can be fertile ground for innovation.

// jeff

In our last portal redesign, we determined that consistency was the number one problem with our interface, in two veins: 1) The overall experience was TOO uniform and looked the same everywhere you went, and 2) Behavior elements like buttons, links, menus and body content were completely different on just about every page, and frequently several times within the same page.

In our redesign, we implemented a principle called “Interface consistency with content creativity”. We normalized all links, menus, buttons and typefaces to one font style and behavior (blue underlined links, etc). At the same time, we added 20-odd slightly different “themes” tied to business units, to give people more visual cues to understand where they were in the 500+ community portal. We relaxed some standards around images and clip-art (ugh), let users be a little more creative in their communications, and the resulting portal is much more “friendly, social and usable” than before (taken from recent surveys).

The statement above, “Interface Consistency, Content Creativity” really helped us clear the cobwebs of what we (as the UCD team) meant by consistency. When communicators & business folks understood we weren’t trying to change the way they communicate, they bought into the concept much more quickly. In fact, I’d say part of our job was to empower communicators by reducing variance in general site behavior, in favor of highlighting the true content that every portal visitor needed to know.

The lesson learned from our previous portal? Creativity is a necessary part of designing an interactive, friendly experience. Inconsistency for purely arbitrary reasons (i.e. because the designer wanted to be different) achieves the opposite of the site’s intended effect - it shifts people’s focus from the content or task to questions like “Why the hell is that button shaped like a wagon?”

I don’t know if I’m agreeing with you or not, but thanks for the post. It’s an important discussion and worthwhile having with any development group who questions the relevance of Section 508, W3C, or corporate web standards.

- Bryan
http://www.bryanminihan.com