Currently I am getting a second degree from MSc Usability Engineering at Rhein-Vaal University of Applied Sciences (Germany).

This program is the only one in Germany entirely dedicated to Usability and HCD. In addition, Usability experts working for companies such as Samsung , Siemens , Wargaming , Porsche, and others usually act as teachers. Moreover, some of the teachers are part of working groups to develop ISO standards for usability .
')
In this and subsequent articles, I plan to share some of the knowledge that I receive as part of training.

Why do I need to know all these standards?

The use of standards provides several significant advantages:

• Saving resources - no need to reinvent the wheel;
• Predictable result - the concepts used in the standards have already been tested many times in practice;
• Simplification of communication - the whole team has a single vision and, most importantly, a single glossary of terms;
• Conceptual view - most standards do not answer the question “How to do it?”, Instead they focus on “Why?” And “What to take into account?”;
• Compatibility - it is assumed that the ISO standards of different series are compatible with each other;
• The simplicity of the “sale” - it will be easier for you to convey your ideas to the leadership if you rely on international standards;
• Certification - relevant for standards such as ISO 9001.

It all sounds pretty banal. It is not yet clear that most of the terms and approaches in Usabillty are not well established. What some call "affordances", others call "signifiers." Many methods have several names. Many concepts (for example, the concept of person) are used as necessary. Thus, standards allow somehow to restore order in the industry.

ISO 9241-110 standard

If we talk about the ISO 9241-110 standard (principles of organizing a dialogue), then it is part of the ISO 9241 standard (Ergonomics and human-computer interaction). The main objectives of the ISO 9241-110 standard are to provide recommendations for analyzing, developing and evaluating (testing) dialogues.

At the same time, the standard aims to prevent such typical mistakes in dialogs as:

• Additional, unnecessary steps that are not required to solve the current problem - the user registers on a free site and is asked to enter the card number;
• Conflicting information in the dialogues - the user has been meditating for an hour on the inscription “one minute left”;
• Lack of information in the dialogs - GPS-navigator does not show the estimated time of arrival;
• An unexpected response to an interactive system - once I saw on the Microsoft website “press log-out to log-in”;
• Ineffective error recovery - submit MS Word without undo button of the last action;
• Restrictions in navigation - the user is going to book a hotel, he is already at the payment stage and then he realizes that he wants to change the dates. The user wants to go back, but there is no “back” button. The user goes to another site;

To solve problems, the standard suggests using 7 principles. I will use English names with the indication in translation brackets from GOST:

1. Suitability for the task (the applicability of the dialogue for the production task);
2. Conformity with user expectastions ;
3. Self-descriptiveness (informative);
4. Suitability for learning ;
5. Controllability ;
6. Error tollerance (error tolerance);
7. Suitability for individualization (adaptability to the individual characteristics of the user).

1. Suitability for the task

The most important principle. If you made a cool application, but it does not solve the user's problems, then you have lost time.

According to the standard, the dialogue is suitable for solving the problem, if it allows the user to successfully solve the problem with minimal effort. How to find out what the user's task is - this is the topic of a separate article. Here we believe that you already know what your user’s goals are.

Recommendations:

• Make the typical values ​​available by default - if the user buys a ticket at the railway station, it would be wise to indicate this as the point of departure;
• Only the necessary steps and information - you have developed a system for a smart home. Every time someone forgot to turn off the tap in the house, she sends a reminder to the user. The user does not want a reminder, simply close the tap automatically;
• Ensure compatibility with physical documents - if your application involves entering some information from a paper document, make sure that the fields in your product match the location and meaning of the fields in the original document.

2. Conformity with user expectations

According to the standard, your application must comply with "contextual user needs and generally accepted agreements."

In order to better understand the meaning of this phrase, it is necessary to understand what the context is. According to ISO 9241-11, the context of use is a combination of the characteristics of users and their tasks, as well as the organizational, technical and physical environment.

It is obvious that the expectations of a student user who is slowly traveling in pairs, and the expectations of an ambulance officer during an emergency call, can vary significantly. Even if they use the same tablet computer. Accordingly, these differences need to be considered in the design.

Recommendations:

• Consider the experience, knowledge and skills of users - for example, older people can expect a larger size of buttons and text in the application;
• Use familiar terms - each industry has its own slang, keep this in mind when developing;
• Make your product complete - if the “OK” button is green, let it be green on all screens of your application;
• If you are going to do something unexpected for the user , warn him in advance about it ( “after performing this action, the next system load may take about 1 hour” ).

3. Self-descriptivness

It follows directly from the second principle. The user should always be clear where he is, why he is here, and what to do next.

Recommendations:

• Provide information on the current status - in most computer games, the player always knows when he is dead and is not surprised that he cannot jump or run;
• Provide feedback - if a user clicks a button, let him know that your program has seen this click ( you can use different types of feedback: sound, change in shape, etc. );
• Users do not read manuals - test your design on real users. Make sure that users understand what to do;
• Explain your expectations - often you expect the user to enter a particular information in a specific format (for example, day-month-year). In this case, it is recommended to explicitly give a hint about the required format.

4. Suitability for learning

The dialogue should support the user and facilitate learning.

Especially important principle, if you "invent the future" and your product does not meet user expectations and is not informative.

Recommendations:

• Explain the "rules of the game" - Kickstarter is a good example. Knowing that their product is new, they tried to do everything possible so that the user understood what crowdfunding is and how to implement it within the framework of Kickstarter;
• Provide suitable support - think about the situation in which your user is in, what he does, what he is trying to achieve and what kind of help he expects from the dialogue;
• Remember that your users are not the same - your users can learn at different speeds, someone may be closer text, someone pictures.

5. Controllability

The user should be able to initiate interaction as well as manage the interaction.

Recommendations:

• Assume the possibility of interruption - what if the user wanted to interrupt the dialogue? What if the dialogue was interrupted by a sudden reboot?
• Enable undo of actions - this applies to both ctrl + z and the ability to press the back button to return to the previous dialog screen;
• Think about input devices - what if the user uses the keyboard and mouse? If only the keyboard? If he controls the voice? If he uses a professional graphics tablet?

6. Error tolerance

The user should be able to reach the goal without (or with the minimum number of) adjustments.

Recommendations:

• Help the user to detect and avoid errors - for example, highlight red fields with incorrect input;
• Prevent “unexpected” system conditions — ideally, user actions should not lead to system abnormal conditions or system breakdowns;
• Provide active support - if an error is found, inform the user about it and describe possible solutions.

7. Suitability for individualization

Very controversial principle, so I put it last.

Classical reasoning: we made a fully customizable interface, so we do not need to worry about Usability - the user himself knows how he is more comfortable. It sounds beautiful, but there are two points. First, the user does not know your product as well as you. Secondly, your user is not an expert in ergonomics and design. Therefore, it is your job to make a user-friendly interface.

Recommendations:

• Think of users with physical disabilities - this type of individualization tends to benefit dialogues;
• Let the user choose a language — as well as secure customization.

Conclusion

In conclusion, I want to say a few words about the use of the standard.

First, the standard is a recommendation and can be viewed as a list of check-points for reflection. For example, if you make an interface for MES, then, according to the standard, consider the possibility of customizing the interface. Most likely, you will decide on the inexpediency of customizing software for emergency situations. However, it is recommended that this solution be explicitly reflected in the working documentation.

Secondly, the standard can be used not only when developing new solutions, but also to check old ones for compliance.

---

I hope that this article seemed to be interesting and worth the time spent. Finally a short survey.