Consistency and Conceptual Integrity
If consistency is your goal I doubt you will ever produce world-class designs.
The importance of consistency, and what consistency really means with regard to software design, has to be one of the most misunderstood and misapplied principles. I am constantly tortured with “well, Microsoft does it like this – why don’t we just copy that? It would be consistent with what users expect.”, and “let’s make this control look like this other one to be consistent”.
With this modus operandi, how can you ever expect to innovate?
Consistency is not about copying existing designs to shortcut necessary creative work (Note: I’m not talking about looking to other designs for inspiration). True, this can be used effectively, and may even be a good idea in some cases – there are many great designs out there worthy of mimicry! But it should not be a standard practice. Should every car look like a Honda? Should every tool in your garage have the same handle?
Should form follow function, or form follow form?
Maybe we should create a standards committee that specifies how all buttons should look and behave; then when someone develops a new software application, they can go to a website and download all the controls they need to build it. Over time all software products will look and behave exactly the same and our users will be much happier, right? I don’t think so.
And even more importantly, consistency does not mean sacrificing usability for the sake of code reuse! Again, I am a practical designer; I understand the various business and engineering considerations (time to market, cost, etc.). I’m not advocating reinventing the wheel. But I certainly don’t think that a bicycle, motorcycle, van, or high-performance sports car should all share the same wheel design either! Code reuse should be leveraged whenever possible but it has to be weighed against other considerations such as basic usability, existing metaphors and mental models, etc.
So, how can one apply consistency correctly? By thinking in terms of “conceptual integrity,” a slightly more abstract concept coined by Frederick Brooks in The Mythical Man-Month. CI means that the software system as a whole should reflect one vision and should fit together seamlessly and flow naturally. This will require consistency throughout the system, but it will not be the driving force. The usage of the system is the first consideration and consistency is applied to support this.
Form follows function and then goes through the consistency/best-practices and usability testing ovens to create the final product.
I agree with your overall tenet that consistency is not the be-all and end-all arbiter of design decisions. Creativity is equally important to the experience and occasionally unique circumstances require varying from the norm(consistency) and/or completely reinventing the wheel. On the other hand, the Wheel example in your post illustrates the boundary between consistency and creativity quite well. You’re right, neither bicycles, motorcycles, vans nor sport cars should have the same wheel design – but they’re all round, have a hole in the middle, are sized according to their load and treaded according to their anticipated use.
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
Hi Russell,
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
Chauncey
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.