Consistency: When is it too much of a good thing?

Consistency in an interface is generally a good idea, but like many good things, it can be taken too far. Particularly in content-heavy web sites, pages with an overly similar look can make it difficult for users to get a sense of place. Too much similarity can also give a system an overall static feel. The key is to understand when a lack of consistency interferes with the user experience—and when it doesn’t.

We’ve found that for any system type, it’s critical that terminology be consistent. Users tend to take terminology at face-value, meaning that when they see different terms they assume each means something different. Or—if the terms are very close semantically and appear on the same page or screen—users will stall and evaluate: which should I choose? On the web, a common example is a page with two or more calls to action: each leads to the same destination, yet they are labeled differently. This is shown in the example below where the two links and the button lead to the same registration page:

Too much of a good thing?

Inconsistent terminology can be a big source of usability problems. And it’s a problem we commonly encounter: usually it’s because different teams work on different areas of a system, with each team using their own set of terms. In theory, inconsistent terminology is a low-hanging-fruit type of item to fix. In practice, because of organizational issues, it can be an uphill battle to get an agreed-upon, centralized set of terms. At Blink, we use Objects and Actions Analysis to identify the important concepts and assign appropriate terms. But even developing a simple alphabetized list of preferred terms can work to keep major terminology conflicts from cropping up.

While it’s important to establish basic navigational conventions, page-specific navigation is an area where consistency can be taken too far and actually make a system more difficult to use. The reason is that different areas of a site can have different information structures: one section may have narrow and deep hierarchy, while another may be broad but shallow. There are also different navigation requirements for areas that involve non-linear browsing, those that involve step-by-step (wizard) functions, and those that are search-based. As long as the navigation approach in each instance is clear and does a good job of supporting expected actions, users normally adapt (after all, users regularly encounter different navigation schemes when moving between sites on the web). This is not, however, a carte blanche for navigational chaos. Every attempt should be made to make the scheme as consistent as possible. Striving for navigational consistency is important not only for your users, but for your development team as well. The rules governing navigation should be simple and clearly articulated so that they can easily be followed. One double-check we use in our design work is if we are having trouble communicating the navigation scheme to the client, we need to go back to the drawing board and simplify.

Related to the navigational scheme is the issue of page layout. Sometimes, the navigational scheme drives the page layout; in other cases, page layout requirements drive the navigation. The latter occurs most commonly with promotion-centric web pages, where the goal is to highlight key content and one or two clear calls to action. Many e-commerce sites now use promotion-centric layouts for top-level product category pages, and a more navigation-focused layout for lower-level pages designed for product browsing. And, finally, product detail pages typically have their own unique layout requirements designed to help “close” the sale.

Though we work primarily with grayscale wireframes, we coordinate closely with visual designers to help bring the design into its full-color visual treatment. Here, a common question is about link color: should there be a single link color or different links colors for different areas of a page or for different link types? It’s easier on everyone—your development team and your users—if you can stick to a single link treatment. But, again, we’ve found users contend fine with some variability here as long as the link treatment clearly communicates that the text is clickable. When links appear in a clearly defined navigation area, such as a navigation bar, users assume that the text is clickable—underlining links is not normally necessary. However, we recommend that links embedded in text do have underlining to more clearly distinguish them from non-clickable (plain) text.

Consistent button treatment is also important. In our wireframes we represent three main button types: primary action (represented by a boldly outlined button), secondary actions (using a button with less visual weight), and tertiary actions (a smaller button with the least visual weight). The goal with these button treatments is to clearly and consistently communicate the hierarchy of actions.

Occasionally, we design pages that by their nature have very similar layouts and navigation schemes. The risk here is a lack of feedback—users navigating between these pages may not perceive a difference and incorrectly assume that they are “not going anywhere.” In these situations, we recommend visual treatments such as icons and imagery to provide more obvious feedback. It is also helpful to provide clear location indicators: for example, highlighting the current location on a navigation bar. Sometimes, however, this isn’t enough. Users tend to focus their attention on the main body of the page and may overlook more subtle changes that occur in the page perimeter.

Overall, our approach is to be consistent where ever possible, but not to force consistency where it doesn’t make sense. Our priority is on making sure we use terminology consistently and to develop a clear but flexible navigation scheme. We work closely with visual designers to be sure that where ever necessary consistency is reinforced and differences are appropriately highlighted.