This is the second of the 10 usability heuristics by Jakob Nielsen.
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.
When you go to a coffee shop and order your favorite beverage, would you like to hear – “Item# 290 has an inventory count of 0 and threw an exception”, or would you like to hear “I’m sorry, we just ran out of that brew. Would you like another?”. I wouldn’t want to hear either, but if I have to I would prefer the second over the first.
Why then do we communicate errors and other information to users from applications with computer jargons no one but the engineering team can understand? It is because designers and programmers do not give much thought to how information should be conveyed to users. Web or business application users are often presented with unfamiliar terms and computer jargons and are required to understand those terms and react accordingly. These terms are often called “geek speak”, and the reality is – it slows learning and frustrates users.
Here is one such example. Let me think of when I last used the words “Abnormal program termination” in a sentence… mmm.. well.. NEVER! And I tried my best, but I really could not find the “Unknown” files. Maybe that’s why there were called “Unknown”.
“Geek speak” don’t make sense to anyone except to the ones who programmed it in the first place. Sometimes even they scratch their heads in wonder.
Designing applications to communicate in plain language is of course hard work, but who said usability was easy to achieve? It requires planning and significant effort to ensure that the right vocabulary and plain human-readable language is used to convey messages understandable to users.
Using the right Vocabulary
When developing a system you don’t have to make up terms for the user-visible concepts in the application, but can use the terms that the user community who performs these tasks already use. It is advisable to not create new vocabulary as these will be foreign to the users and would require them to learn the new names making their tasks all the more difficult.
For example, when building a business application to track time for people working on a project, if the objects used to track them are called “Item”, “Sub-Item” and “Hours” in the data model, but if the business users are familiar with the terms “Project”, “Tasks” and “Efforts” respectively, then that’s the best way to refer them in the application. Using the term “Sub-Item” would require the users to learn that it actually means a “Task” to them. This causes users to use more conscious mental decoding methods leading to decrease in productivity.
This is done by creating what is called an application “lexicon”. The lexicon gives a name for each object, action or property exposed to the user by the application. The lexicon can emerge from user interviews and observations of users, and typically, users, user interface designers, developers and technical writers all help create the lexicon. The lexicon has to be consistently followed throughout the application, the user manuals, and so on.
When designing an online store, while using the term “Trolley” may sound cool, “Shopping Cart” would be a better term that all users would easily understand.
A good vocabulary would be:
- Task- focussed – names would be focussed on the task not on technology.
- Familiar – does not introduce a new vocabulary, but uses the one that is familiar to users.
- Consistent – does not use different terms for the same concept. For example, “product” and “item” are not used to refer to the same thing.
Do not err on error messages
Avoid needing exceptions and error messages in the first place. However, when having to display them clearly indicate that something has gone wrong in a non-alien language. Be polite and do not blame it all on the users for their low IQ. Be constructive and let them know how to fix the problem while offering suggestions. Educate users if necessary, by providing links to resources that explain the problem and how to avoid them.
Here is an example of a good error message:
At the end of the day
It does take additional effort to communicate to users using real-world conventions. However it does pay off. When the terminology is familiar to the users, using the application becomes automatic and reduces the time it takes them to master your application. With lesser frustrated users and fewer support related problems, you could now have the time to go order your favorite brew. This blog entry has “Terminated Normally”.
About MeI'm Tingu Abraham. Everybody calls me Tingz because it sounds so cool (and because I paid them to). I’m obsessed with information architecture, UX design, new technologies and playing music. In my spare time I keep wondering why 24 hours a day are just not enough.
- Usability Heuristics – Part 10 – Help and documentation
- Usability Heuristics – Part 9 – Help users recognize, diagnose, and recover from errors
- Usability Heuristics – Part 8 – Aesthetic and minimalist design
- Usability Heuristics – Part 7 – Flexibility and efficiency of use
- Usability Heuristics – Part 6 – Recognition rather than recall