Let’s discuss Jakob Nielsen’s 10 usability heuristics. When you read these guidelines you probably nod and think “yes, that’s right”, but the problem is with execution because there are no concrete examples and correct solutions for them. I will try an example which illustrates that guideline is really about. Most of examples are from my experience while working on the enterprise application. I’ve spotted similar problems before I have heard about Nielsen’s heuristics so you probably might be already familiar with them even if you don’t know them.
1. Visibility of system status
The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
Imagine a form with a button at the end. Once you’ve filled all fields in the form you click the save button and
… nothing happens.
… you are redirected to some other page in the system.
… save button disappears and Ok button shows up.
You might have seen systems like this before. Each share the same problem. System status, concretely status of the operation is not shown. It would be much better if user sees notification message about successful operation. If action takes time then immediately after save button has been clicked some kind of in progress bar should be shown. These little things communicate to user that something actually is happening.
I had countless of situation where I was unsure whether I clicked the button or not. Then I clicked it again and after a while I could get an error because of operation in progress. Sounds familiar?
In short: React to user actions, show notifications upon success and error, show progress bars for time-consuming actions.
2. 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.
I would argue here and take this guildeline further. I would say that system should be oriented in real-world nomenclature so that interface and real-world convetions are natural consequence of whole approach to product development.
However to give an example. Let’s say that form from previous example was for opening a bank account. Let’s say that operation failed and we do see notification.
Instead of notification with generic message Operation has failed it’s much better to see We couldn’t process your account opening request because …
Giving the reason of the failure is not the point in this case, but using a words of the domain is.
3. 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.
This guideline acutally says exactly what we should do. However Undo and Redo is not always a valid options. Having a Cancel everywhere is a good idea. Closing modal windows with Escape key also. As well as with usual close icon. In the last system I’ve been working on modals could be discarded in every way mentioned. User should be familar with majority of them.
4. Consistency and standards
Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions
This is very important guideline which can be breached easily when there are no clear standards and there are many developers implementing the system. The simplest example is the name of the save button. Is Add the same as Save? These inconsistencies were a commonly reported errors.
Placement is very important as well. If you have different actions on one page and similar set of actions on other page but in different order and/or different location relative to the content then user might be confused.
5. Error prevention
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.
Very good example is form validation. Obviosuly you need to check data at the backend so you already have one validation there. One might start questioning validation done at form level, but it greatly increases usability and decreases amount of errors user can see. Validating dynamically each form field is a right way to go. Once a user finishes with one field it should be validated and marked as valid or invalid (remember first rule?). If it’s invalid then message should be shown. Even better message with correct example.
6. 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 haven’t run into issues with the first part. It is a common sense to make a information visible if it is required to proceed later. I can however give a practical advice on the instructions.
Following standard conventions it might a good idea to put a small icon symbolising help for example question mark which when hovered displays instructions about how to proceed further. It is particularly good because instructions are then focused on the problem, they are always close to origin of the problem. Also the fact that they are hidden until needed is also good because otherwise user could be overwhelmed of information.
7. 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.
I had no previous experience with that one. It is definitely a good idea. Shortcuts to everything is the reason I love IntellJ so much. However there is no easy way to help novice user advance on higher level. They must want to do that by themselves and so they will look at documentation for shortcuts.
In my point of view, this guideline is like a cherry on top. There are more urgent issuses to deal with first. Making navigation faster is a easy when there is a good navigation in the first place.
8. 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.
Nightmare of every enterprise application. How to cut down on all this required information? If user needs to fill 100 fields because business say so then there is no way around limiting these 100 fields. However there is a way of making it seems like less. Multipage forms are a good way to go. If we can divide these fields into related groups and in 99.99% it is possible then it is much better to ask user just for a bit of information and then advancing for the next step. Again it is important to remember about 1. and showing how many steps are ahead.
9. 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.
I have already gave an example of this in 2. but then solution wasn’t the point. Look at the difference between these two messages:
- You cannot order this item.
- You cannot order this item because it is out of stock.
What are your thoughts on the first? Mine are like “Why? Am I not good enough for you or what?”
Second is better however it can be even more better. What is missing? Suggestion for a solution. How about something like:
“You cannot order this item because it is out of stock. Click here to be notified when item is back in stock”.
Now you have it all.
10. 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.
Writing a good documentation is a tough task and no one wants to do it. If it has to be done then it is done by the least experienced team member whos time is least expensive. That’s the reason why most of the documentation really sucks.
Using contextual help like that from 6. might a good idea. In that way there is no one big documentation but there is always a contextual documentation in hands reach.
Summary
At this point I am pretty sure that you have run across at least one of these issues and you knew what you could do. Knowing these guidelines might make you more consious about the problems. There are very easy solutions to most of them. In most cases there are already open source frameworks and collections of other components which can be used. It just requires a little more effort. It is something like Pareto rule “20% more effort gives 80% better usability”. Even though it’s not time consuming it is often something that it is done at the end when deadlines are already breached or close by and bug reports are already coming in so it might be hard to put that additional effort. At least that’s from my experience.