Why you should question everything about your product design?
Ever heard about Nielsen’s 10 Usability Heuristics? If not, I think you’re kinda late to the game. Nielsen’s 10 Usability Heuristics are Jakob Nielsen’s 10 general principles for interaction design that put forward 25 years ago😮. They are called “heuristics” because they are broad rules of thumb and not specific usability guidelines.
Nielsen’s 10 Usability Heuristics
Today, those heuristics are just as relevant as they were then. Nielsen’s 10 Usability Heuristics are valuable guidelines that can help us make usable products for everyone. They can help to save development teams considerable amounts of time during early usability testing so that they can direct their attention to more complex design challenges. In addition, it’s also worth it to use them as a checklist when designing a new product or a feature.
In this article, I attempt to explain these 10 rules in common language with examples that have been implemented in creating mockups for my team’s product (Document Builder).
Before jumping into the explanations, here’s the sneak peek of Document Builder's high-fidelity mockups that I designed in Figma.
1. Visibility of system status
The system should always keep users informed about what is going on, through appropriate feedback within a reasonable time. Users love to keep things under control, and only then they can feel secure. The sense of control can be evoked by providing information about the system status and feedback every interaction.
To make sure users know where they are in Document Builder, we (Group A8) highlight the active page which can be seen from the sidebar so that users get the info of the page they are currently on.
Other than that, we’re also going to implement breadcrumbs. What are breadcrumbs? A breadcrumb is a small text path, often located at the top of a page indicating where the user is on the site. It allows users to make selections from a range of values.
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. In other words, people presume how the system could work based on their experience with other systems that are similar. It’s also important for the application to speak the language of the target user base.
In Document Builder, we use Bahasa Indonesia as the main language because our target users are all Indonesians. Unfortunately, there are some words in Bahasa that are less knowledgeable than they are in English. For example, “template”. I believe everyone is familiar with the word template. For those who don’t know what template means, it’s a file that serves as a starting point for a new document. Now, let’s translate it to Bahasa Indonesia.
The truth is, as an Indonesian, I have never heard people here using the word templat before. It’s not a common word rather than a template. Therefore, we had chosen to keep using the word template in our product. We did talk about this before with our client, we tried to come up with ideas several times, but alas, there seems no suitable word to cross out “template”.
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 principle can be best illustrated by the modal message that could be found if users clicked the “Hapus Template” button. This modal prevents users to actually delete the letter template when they, perhaps, clicked the “Hapus Template” button by mistakes.
4. Consistency and standards
Users should not have to wonder whether different words, situations, or actions mean the same thing. Consistency is the key. A comprehensible system should never confuse users by using different words, visuals, or actions for the same concepts.
I created Design System Guidelines for a good starting point for a consistent design. Click here to read the article about Document Builder’s Design Guidelines. By the way, the article is written in Bahasa Indonesia hehe.
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.
Based on Don Norman’s book The Design of Everyday Things, there are two kinds of errors created by interaction with a user interface: slips and mistakes.
Slips happen when the user tends to do an action, but due to low attention, performs another one (e.g. when performing well known task)
In Document Builder, we use constraint that reminds users to upload a document when they’re trying to create a new template of letter. The reminders would pop out in the middle of the screen if users forgot in inserting the document and clicked the submit button instead.
Mistakes are often caused by a user’s incorrect mental model of how the system works.
These kinds of errors don’t often come with an easy fix, and they should be revealed during the user testing phase. Use clear communication and a consistent design system to prevent mistakes.
An example of implementation can be shown in every input form on Document Builder that is left empty or not having the right value. The system would check the value of the forms once the users click them. We try to validate every input form as the users type rather than waiting for users to click submit.
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.
In this section particularly, we got input from PPL’s teaching assistant regarding our High-Fidelity Mockups. She said that our product is still lack of filter feature for filtering the template list by the submission status. Therefore, I added a filter feature in the form of chips that are divided into four categories which are Semua, Baru Diajukan, Diproses, dan Selesai. This filter minimizes the application of user memory in knowing every letter template that has been submitted.
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.
A good user interface should offer appropriate functionality to both inexperienced and experienced users. Declutter the screen and make the app easier to navigate. The app should always display only relevant UI elements and commands.
An example of implementation is when users creating a new letter template, there are a few input forms related to the template.
But when users decide to upload a document, whole new input forms specifically curated to help users complete the task appears.
Moreover, the field type selection is only showing the additional relevant input form based on the users’ desired type for the field.
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.
Keeping our app minimalist and clean. This helps users focus on their tasks and highlight the goal of each page. Interfaces need to be cleared of unnecessary elements and content that do not support the page goals and tasks.
Below is one of the examples of our minimalist design.
This page’s purpose is to provide a way for users to register on our website. Hence, we only put relevant input forms that are required to make an account. Other than that, we use white space for the minimalistic and sophisticated part.
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. Give the user some constructive advice on what to do next. The last rule of good error messages is politeness. Never blame the user or imply that they’re stupid.
If the users submit an empty form, this example of an error message above will state the mistake which immediately suggests the next step.
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.
Document Builder hasn’t had any plan in developing a Help Page or a Frequently Asked Question Page. Our main goal, for now, is far from building a page that provides the documentation of the website. But this idea to implement might be considerable.
Although the idea of making a “mockup” sounds easy and all, it really doesn’t. I’m not saying it’s hard, but you need to put an effort if you’re really designing for users and not yourself. Keeping your design under Nielsen’s 10 usability heuristics will help you do so much. Keep in mind that these are called “heuristics” for a reason — they’re not specific, it’s up to us designers to decide.
