Nielsen heuristics

It is important to remember that heuristics are general rules of thumb and not specific usability recommendations. Always, when considering a particular issue, one should also take into account:

¨NBSP;

1. The design system,
2. the specific user scenario,
3. development constraints.

Here we will describe how our UX designers use Nielsen's 10 heuristics in their work on the SimpleOne platform:

1. System state visibility

The interface should tell the user the state of the system. However, it should be remembered that the abundance of signals creates information noise. Such signals should be graded according to their importance to the user: the most critical errors should be visually highlighted most brightly, while more ordinary messages (e.g., about the success of an operation) should not be so prominent on the screen. This heuristic also applies to such familiar things as highlighting in the navigation (shows which section you are in now), the state of focus at the input field (signals that you can start typing text), loader on loading (means that the process has started).

2. Correspondence between the system and the real world

In SimpleOne business process automation system we try to make everything so clear that not only a system administrator, but also, for example, an accountant could understand it. In specific interfaces we allow complex terminological formulations, but always accompany them with a hint, so as not to force an inexperienced developer to constantly refer to the documentation. As for elements universal for any software (for example, designation of drag&drop area, icons, scroll), here we are guided by generally accepted rules of component design: drag&drop area should be labeled, icons should be signed (for example, we use hover hint), scroll should look like a scroll.

3. User control and freedom

The user should know what they can do in the system and what their actions will lead to. This will avoid fear of interaction with the software and disappointment in case of errors. If an action cannot be canceled, we warn the user about it and give him a chance to think again. In the interface design, we try to make sure that the user understands how they can "exit" the scenario or "return" to where they were. For this purpose, we have "cross", "cancel", "arrow", and "breadcrumbs" icons.

4. Consistency and standards

The less new things a user has to learn when interacting with the interface, the faster and better the user works with the system. To avoid cognitive load, we, firstly, try to adopt interface patterns familiar to our audience, and secondly, we use the same element designations within SimpleOne. For example, we use the chevron icon to denote "nesting" everywhere. When you click on an element, additional information appears: the activity feed, menu sub-items, and previously hidden text unfolds.

5. Error prevention

To minimize the number of user errors, we use hints for: buttons, fields, forms. We try to tell how to interact with this or that element. We warn users about the consequences of certain critical actions with the help of a dialog box.

6. Recognizability, not recollection

You don't want to implement a user scenario in such a way that the user has to remember something, especially if the information was given in a previous step or on a different page altogether. If a single process is set up in different parts of the system, you should broadcast the necessary information on the current screen at each step. It is also desirable to minimize scrolling on the form. For example, we have "info" widgets that can immediately tell the ITSM agent about the most important parameters of the incident and provide the contacts of the subscriber without forcing him to go to the profile card.

7. Flexibility and efficiency of use

Each user has a different approach to interacting with the interface and a different individual experience. For some people the prompts are necessary, others do without them. Some people click on the "cancel" button and others on the "cross" button, even though they perform the same action. Someone is used to getting to the desired section with the help of search, someone else finds it easier to open the navigation, and many people use the address bar at all. All these users should be supported equally: create clear and memorable table names, duplicate the "cross" with the "cancel" button in the modal window, and add the function of closing the window with the Esc key for advanced users.

8. Aesthetic and minimalistic design

The more information on the screen, the harder it is to see the main thing. That's why we hide minor information in menus, behind "help" and "info" buttons, behind links. We display the most important things on the page: the title of the current location, information about the entity, give access to related elements. We highlight in color only the target action, for example, the "save" button. We leave only the main actions available for one-click access, and hide the rest, such as "customize view", in the burger menu.

9. Helping users to fix errors

To highlight errors, we make the text understandable to all users, constructively state what happened and, if possible, offer a solution. For more experienced users we provide a link to logs where they can diagnose the causes of the error. For less experienced users, we help them contact support. Depending on the context, we divide errors visually: an error when accessing a page (stub page) is displayed on the whole screen, an error when saving a record is displayed in a dynamic window on the right (tost or flash message).

10. Help and documentation

Documentation is handled by our department of technical writers. In their articles, they tell step-by-step what is presented on the screen and what a particular entity exists for, how to set up processes correctly, what errors can happen and how to fix them. Of course, it's best to minimize the user's trips to the documentation, which we do with field hints and help information on forms. However, the instructions should always be at the user's fingertips. Now we are on the way to specialize our documentation by roles, as we understand that ordinary users don't need much of the instructions, but developers would like to get to the description of specific settings as soon as possible.