Usability Principle #9: Consistency
Consistency is another one of these principles — right alongside what I’ve called “familiarity” — that seems to automatically make most people’s list of usability concepts. It’s a relatively easy case to make: consistent design can make it easier for people to navigate new applications and new functionality, while inconsistent design often confuses.
As with familiarity, I also believe that consistency is an important principle — one that we should try to implement where possible — but I also worry that consistency taken too far can be problematic. As Mark Twain said, “To a man with a hammer, everything looks like a nail.” If we find ourselves struggling against reason to shoe-horn a design into our favorite mold, we should step back and reconsider.
To me, the problem with consistency — and the reason it comes last on my list — is that it does not really solve any problems. In other words, consistency alone does not make interfaces intuitive, it only helps us if we already understand the original intent. That said, consistency can be a big help to “expert” users (for example, keyboard shortcuts for cut, copy, paste, undo, open, close, and new are just about the same in most graphical applications today), and lack of consistency can be a real problem.
Consistency is relatively easy to achieve in software applications today. Back in the mid 1980s, Apple began publishing a series of books called Inside Macintosh. The early books in the series read like a style guide for GUI applications – how many pixels tall the title bar in a window should be, the proper offset for buttons, how to implement text scrolling, etc. Later, however, these books morphed into documentation for the Application Programming Interfaces (APIs) that Apple provided to developers as part of the operating system. Today, few developers bother to challenge the building blocks of user interface, instead choosing to rely upon the APIs built into the operating system. While this approach has dramatically accelerated the rate of GUI application development, it also presents a barrier to customizing interfaces around a particular task or function.
On one extreme, HTML makes it particularly easy to achieve a consistent user interface with minimal effort. A few words in a text document are all that we need to program our browsers to spit out buttons, text boxes, labels, check boxes, and drop down lists. On the other hand, these tools are not always appropriate, and it is in many ways harder to implement a custom control on a web page using JavaScript than to make a custom control for a Windows, Mac, or Linux desktop application. The other extreme may be video games, where user interfaces are often unique to each game. On the web, content seems to matter more than interface; in the video game, interface matters as much or more than content.
So, what’s the answer? When should we strive for consistency, and when should we break the mold to deliver a unique interface that is optimized for an application? I believe that we should consider consistency alongside one of the earlier usability principles: proximity. Given two conceptually proximate functions (for example, undo, cut, copy, and paste are nearly universal functions today), we should strive to maintain a consistent interface (in this case, the same keyboard shortcuts, placement of these commands at the top of the Edit menu).
I have written about the iPhone before, so please forgive me for bringing it up again here. One thing that I like about the iPhone is that its interface is tailored to the device. The home screen is reminiscent of that other easy to use device, the Palm Pilot — with application icons laid out in a grid, the four most major of which run along the bottom of the screen. By contrast, the iPAQ/PocketPC/Windows Mobile 
interface stubbornly retains the Start menu, a Desktop, a Control Panel, and windows stacked in Z-order throughout the operating system. Personally, I do not feel that these patterns work nearly as well on a small screen and without mouse or keyboard as they do on a regular personal computer. However, I think it would be confusing if devices like the iPhone or the Palm Pilot had strikingly different interfaces within each application. Thus, functions that are proximate to one another — physically (i.e., on the same device) or conceptually (i.e., playing the same role) — should have similar interfaces. The further apart two functions are, the more we should be willing to tailor their particular environments.