I am currently receiving my second degree in MSc Usability Engineering from the Rhine-Waal University of Applied Sciences (Germany).

This program is the only one in Germany dedicated entirely 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 members of the ISO standards working groups for Usability .

In this and subsequent articles, I plan to share part of the knowledge that I receive as part of the 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 vocabulary of terms;
• Conceptual view - most standards do not answer the question “How to do it?”, Instead they focus on “Why?” and “What to consider?”;
• Compatibility - it is assumed that 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.

All this sounds pretty commonplace. Until it turns out 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 a person) are used as necessary. Thus, the standards make it possible to somehow restore order in the industry.

ISO standard 9241-110

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

At the same time, the standard is aimed at preventing such common mistakes in dialogs as:

• Additional, unnecessary steps that are not required to solve the current problem - the user is registered on the free site and he is asked to enter the card number;
• Conflicting information in the dialogs - the user has been meditating for an hour on the inscription "one minute left";
• Lack of information in the dialogs - the GPS-navigator does not show the estimated time of arrival;
• An unexpected response from an interactive system - I once saw on the Microsoft website “press log-out to log-in”;
• Ineffective error recovery - imagine MS Word without a button to undo the last action;
• Restrictions on 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 indicating in brackets the translation 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 (controllability);
6. Error tollerance (error tolerance);
7. Suitability for individualization (adaptability to 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 tasks, then you have lost time.

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

Recommendations:

• Make typical values ​​available by default - if the user buys a ticket at the railway station, it would be wise to specify this as the departure point;
• Only the necessary steps and information - you have developed a system for smart home. Each time someone forgot to close the tap in the house, she sends a reminder to the user. The user does not want a reminder, just 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 of the original document.

2. Conformity with user expectations

According to the standard, your application must comply with the “contextual needs of users and generally accepted conventions.”

To better understand the meaning of this phrase, you need to understand what context is. According to ISO 9241-11, the context of use is a combination of user characteristics and their tasks, as well as the organizational, technical and physical environment.

Obviously, 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 must be considered in the design.

Recommendations:

• Consider the experience, knowledge and skills of users - for example, older people may expect larger buttons and text in the application;
• Use familiar terms - each industry has its own slang, take this into account when developing;
• Make your product holistic - 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 about it in advance ( “after completing this action, the next system boot may take about 1 hour” ).

3. Self-descriptivness

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

Recommendations:

• Provide information about the current status - in most computer games, the player always knows when he died and is not surprised that he can not jump or run;
• Provide feedback - if the user clicked a button, let him know that your program saw this click ( you can use various types of feedback: sound, shape change, etc. );
• Users do not read manuals - test your design on real users. Make sure users understand what to do;
• Explain your expectations - often you expect the user to enter this or that information in a certain 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.

An especially important principle is if you are “inventing the future” and your product does not meet the expectations of users and is not informative.

Recommendations:

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

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 dialog was interrupted by a sudden reboot?
• Allow cancellation of actions - this applies to both ctrl + z and the ability to press the back button to return to the previous dialog screen;
• Think of input devices - what if the user uses a keyboard and mouse? If only a keyboard? If he controls the voice? Should he use a professional graphics tablet?

6. Error tolerance

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

Recommendations:

• Help the user detect and avoid errors - for example, highlight red fields with incorrect entries;
• Prevent “unexpected” states of the system - ideally, user actions should not lead to abnormal states of the system or its breakdowns;
• Provide active support - if an error is detected, 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 don’t need to worry about Usability - the user himself knows what is more convenient for him. 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 a specialist in ergonomics and design. Therefore, it is your job to make a user-friendly interface.

Recommendations:

• Think of users with physical disabilities - this kind of individualization usually works to the benefit of dialogs;
• Let the user choose the language - also safe customization.

Conclusion

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

Firstly, the standard is advisory in nature and can be considered as a list of check points for reflection. For example, if you are making an interface for the Ministry of Emergencies, then, according to the standard, consider the possibility of customizing the interface. Most likely, you will decide on the inappropriateness of customizing software for emergency situations. Nevertheless, it is recommended to explicitly reflect this decision in the working documentation.

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

---

I hope you found this article interesting and worth the time. Finally, a short survey.