How the 10 usability heuristics coexist within one product
Checking Gmail against the usability heuristics
The other day I have read an interesting article on UX Booth about the ’14 cognitive dimensions of notations’ and how they can be applied to evaluate usability (link). This framework leans more toward being a way to structure the discussion, rather than guidelies for usability — that is, because some points are not necessarily positive or negative. For example, abstraction:
Abstraction gradient: What are the minimum and maximum levels of abstraction exposed by the notation? Can details be encapsulated?
The presence of multiple levels of abstraction is not on its own good or bad for usability, it depends a lot on how elements and their relations are represented. This is rather a discussion point, than a guideline.
That brought me ‘back to the roots’ — to reviewing old but still quite good Usability heuristics. While researching this topic I found a lot of articles and showcases of different features of different products. I found no examples where these principles would be illustrated within the same product. I want to fill that void and use the example of Gmail (not the newer Inbox) to investigate how these principles co-exist withing one product.
Visibility of system status
The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
Basically, the user has to know what is going on in the system, but only if it is relevant. For example, when you hit Send, you get a temporary display that your email is being set. Adding other technical system details of what the system is doing would be potentially unnecessary.
Match between system and the real world
The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
It is often easy to spot interfaces which were designed by following how the system works, instead of how it would be clear for the user to understand it. An example here is the menu item ‘Message text garbled?’. This item clearly stands out, as all the other menu items are actions. What this one should be instead, is ‘Encode’. But, is that the word that the average user would use to describe it, or even know at all? Instead, the designers opted for a cleared description of the situation to help the user, rather than keeping the list of items technically, but impractically consistent.
User control and freedom
Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.
People make mistakes, all the time — because they are tired, distracted, new to the interface. The system should anticipate that and offer a safety net of easy Undo’s.
More times that I would be able to count have I misclicked on ‘Mark as spam’ button. Luckily, Gmail offers an easy undo for that. Also, marking as ‘Not spam’is readily available when you are double-checking emails in the spam folder.
Consistency and standards
Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
When designing a complex system, especially with multiple designers, it is easy to become inconsistent in the interface structure or language use. This can be very confusing at times. Luckily, Good Guy Gmail have again a good example of consistently naming labels ‘Labels’ in various parts of the interface.
Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.
How many times have you seen a dialog window with a text like “Are you sure you want to do this? You cannot undo it’. This is a fair point — it is important to let the user know about the implications. However, in some cases, when deleting something permanently is less of a life-or-death decision, for example, in an inbox, it is possible to neatly call the button ‘Delete forever’. No questions asked.
Recognition rather than recall
Minimize the user’s memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
I like it how Gmail reminds you that old emails that you deleted more than 30 days ago will be removed automatically. The interface anticipates the question/concern and addresses it.
Flexibility and efficiency of use
Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
Not everyone gets to be a pro in every interface, and that’s only natural. But it is a piece of cake when there is extra functionality which makes your life easier when you do become a ninja in a specific software. A good example of it are the keyboard shortcuts available in Gmail
Aesthetic and minimalist design
Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.
It is seductive to dump all the knowledge you have onto the user when they ask something, but it takes patience and skill to cut it down to only what (s)he needs to know. Below is a nice example of a concise yet informative email from Gmail.
Help users recognize, diagnose, and recover from errors
Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
Got the wrong Bob? Sent an angry email you are already regretting within one second? No problem, you have an option to undo the sending of the email.
Help and documentation
Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.
Another example of clear and concise language use in Gmail is the Help portal. The copywrighters managed to explain the functionality simply, yet without patronizing.
It was nice to scavenge Gmail for the examples of the heuristics. It is pleasant to know that the usability of the software I use almost gaily is on such a high level.
It would be interesting, though, to check out some less polished software, and see how evaluating it according to the heuristics can improve the usability of it. Got anything in mind?