The Principle of Least Astonishment: “When two elements of an interface conflict or are ambiguous, the behavior should be that which will least surprise the human user.”—Wikipedia
By maintaining consistency users learn more quickly, this can be achieved by re-applying in one part of the application their prior experiences from another. An added bonus of keeping elements consistent is that you can then use inconsistency to indicate to users where things do not work the way they might expect. Breaking consistency is similar to knowing when to be unconventional as mentioned above.
The following four consistency principles, taken together, offer the interaction designer tremendous latitude in the evolution of a product without seriously disrupting those areas of consistency most important to the user.
The following list is ordered from those interface elements demanding the least faithful consistency effort to those demanding the most. (Many people assume that the order of items one through six should be exactly the reverse. This can lead to real confusion as users confront pages that look familiar, but act completely different.)
Platform consistency: Be generally consistent with de jure & de facto standards
In-house consistency: Maintain a general look & feel across your products/services
Communicates brand and makes adoption of your other products and services easier and faster
General look & feel communicates family
A visual designer should establish a purposeful & well thought-through visual language, shaped by usability testing. User behaviours should be fully transferable throughout the product.
The appearance of such objects needs to be strictly controlled if people are not to spend half their time trying to figure out how to scroll or print. Their location is only just slightly less important than their appearance. Where it makes sense to standardise their location, do so.
Invisible structures refers to such invisible objects as Microsoft Word’s clever little left border that has all kinds of magical properties, if you ever discover it is there. It may or may not appear in your version of Word. And if it doesn’t, you’ll never know for sure that it isn’t really there, on account of it’s invisible. That is exactly what is wrong with invisible objects and why, if you insist on using them, rigid consistency becomes so important.
Apple apparently thought this was a good idea and started copying Microsoft by adding invisible controls from scroll bars to buttons everywhere. The situation on the Mac got so bad that, by the early 2010s, the only way a user could discover how to use many of the most fundamental features of the computer was to use Google to search for help. (For more, see: Discoverability)
Some objects while, strictly speaking, visible, do not appear to be controls, so users, left to their own devices, might never discover their ability to be manipulated. If you absolutely insist on disguising a control, the secret rule should be crisp and clean, for example, “you can click and drag the edges of current Macintosh windows to resize them,” not, “You can click and drag various things sometimes, but not other things other times, so just try a lot of stuff and see what happens.”
Objects that convey information, rather than being used to generate information, should rarely, if ever, be made invisible. Apple has violated this in making the scroll bars on the Macintosh invisible until a user passes over them.
Changing your interpretation of a user’s habitual action is one of the the worst things you can do to a user. Shortcut keys must maintain their meanings. A learned gesture must be interpreted in the standard way. If the button that carries the user to the next page or screen has been located at the bottom right for the last 30 years, don’t move it to the top right. Changes that require a user to unlearn a subconscious action and learn a new one are extremely frustrating to users. Users may not even realise what has happened and assume that something has failed in their hardware or software.
If you want to attract existing users of someone else’s product to your product, you should try to interpret your new user’s commands in the same way by, for example, allowing them to reuse the same shortcut keys they’ve grown used to.
Case Study: Apple “Command” Modifier Key
It was years before Apple finally gave Windows users a simple way to continue to use the Control key, rather than the Command key, for their keyboard shortcuts. Windows users new to Mac faced great difficulty in unlearning/relearning such an ingrained habit. Users having to switch between the two operating system as they moved between office and home had to unlearn/relearn twice a day and would end up constantly making errors as well as having to set aside their task to consciously consider what modifier key to press each and every time they wanted to make use of “shortcut” keys that were shortcuts no more. A large percentage of the difficulty in switching or using dual operating systems was due to this one missing capability, and it was a completely unnecessary hindrance from the start.
Make objects that act differently look different. For example, a trash can is an object into which a user may place trash and later pull it back out. If you want to skip the “and pull it back out” functionality, that’s fine. Just make it look like an incinerator or shredder or anything other than a trash can.
Make pages that have changed look changed. If someone encounters an unfamiliar page on an updated website or in a revised app, they know to look around and figure out what’s different. In the absence of such a cue, they will attempt to use the page exactly as they have always done, and it won’t work.
If you come out with a completely re-worked area of your product or even a completely new product, it is important that people instantly recognise that something big has changed. Otherwise, they will jump into trying to use it exactly the way they always have and it just isn’t going to work. “Uniformity” would mean that your next product would be identical to your last, clearly wrong, but “consistency” is little better in a field where so much growth will continue to take place. Our goal is continuity, where there is a thread that weaves through our various products and releases, guiding our users, but not tying us to the past.
It doesn’t matter how fine a logical argument you can put together for how something should work. If users expect it to work a different way, you will be facing an uphill and often unwinnable battle to change those expectations. If your way offers no clear advantage, go with what your users expect.
Case Study: The Xerox Star Drag Rule,
The rule proposed for dragging icons in the Xerox Star Finder was a paragon of elegance:
Proposed Rule: Dragging a document icon from one object (e. g., a folder or disk) to another on the desktop will move the document
Easy to learn. Easy to understand. Logical. Teachable. Terrible. The rule, to be fair, worked well most of the time. It even worked better in some circumstances than the far more complex rule we use today. For example, if you dragged a document from the folder on your desktop to a floppy disk, it moved the document, rather than making a copy on the floppy. If you then made changes to the document at home, using the document now on the floppy, when you slid the document back onto your desktop at work the next morning, you didn’t have the new version as well as an obsolete version left there the day before. You just had the one true version.
Everything worked well until it was time to print on the Xerox Star. At that a point, you would grab the document and drag it onto the printer icon. The document was transferred to the printer and erased forever from the desktop. A two-week war erupted between the engineers and the designers. The designers won, putting in place the rule we have today:
Final Rule: Dragging a document within a logical volume will move it. Dragging it from one logical volume to another will copy it
99+% of our users could not possibly tell you what a “logical volume” is, yet they understand the rule without our having to explicitly teach them. Why? Because it is consistent with user expectations, part of which is a very strong expectation that carrying out a routine activity will not result in the destruction of their work.