This article was created based on the presentation made at the SQA Days conference . The article was first published on GUI.ru and now I would like to discuss the usability guideline with the people of the world.

Ease of use of the product, high user qualities are an important competitive advantage in the market, where most manufacturers offer approximately the same functionality. As the most relevant example, we can cite the mobile phone market, where convenient and easy-to-use phones are most demanded and well sold (this is due to the success of the iPhone and the transition to touch screen).

What should be understood as usability? The definition of usability is given in the ISO 9241-11 standard as the degree of efficiency, productivity and satisfaction with which a product can be used by certain users to achieve certain tasks in a specific context.



With errors that adversely affect our productivity and satisfaction, we encounter everywhere in real life. Whether it is the obligation to fill out unnecessary fields in application forms and inquiries; mandatory requirement to provide some documents and certificates, which objectively there is no need, but which the procedure requires; idle in queues and traffic jams, etc.


It is not surprising that this practice is carried over to everything that a person creates, including software and websites. You must understand that no one creates bad systems on purpose. Even the most experienced specialists and large manufacturers make mistakes.

Changing the development paradigm

Albert Einstein said that it is impossible to solve the problem, being inside the system that generated it. Until the demand for high user qualities and the use of usability practices become an integral part of the software production process, products and websites will appear that are difficult or even impossible to use.

As an example, consider a form whose fields can only be filled in a strictly specified format. During testing, this form may not cause suspicion even in the most sensitive QA. Formally, it passes the test - when entering data not in a format, it will show an error, while entering the correct ones it will skip further.

But how in the future will those who will work with this form? Each field is filled by trial and error, which becomes a real nightmare for users. This leads to inefficient operation. Such an implementation of the remaining screen forms in the program will necessarily lead to complaints of inconvenience in the work and rejection of automation. And this, in turn, can lead to the failure of the entire project to introduce new software. To change the situation, one should change the paradigm of thinking during development: it is better to prevent the appearance of errors than to limit oneself to measures to eliminate them.

High usability of the product is achieved by introducing the UCD approach (User Centered Design or user-oriented design) into the development. This approach is characterized by the active involvement of the user in the development process to achieve an understanding of user requirements and the proper distribution of functions between users and technologies, as well as the iterative nature of the approach and its multidisciplinarity (ISO 13407). The practice of User Centered Design allows you to reduce development costs and increases the effectiveness of the product, both in business terms (additional profit) and in user satisfaction (increased loyalty to the product and the development company). This approach is applied throughout the life cycle of software creation and includes: definition of requirements, analysis, design, testing, assessment and subsequent refinement of the interface. At the moment, large companies, both western (Microsoft, Google), and Russian (Beeline, RTS, 1C) are introducing UCD practices into their processes. This approach requires the company a certain level of maturity, clearly defined processes and some investments (training, organizational expenses, hiring staff, etc.).

Usability guidelines

Being a realist, I understand that these requirements are still too high for most small and medium-sized companies of web developers and web studios in Russia, and especially Belarus. Their main needs in this area are to quickly (at a low cost) determine (set) the required usability level for their projects and products, formulate requirements and recommendations, set criteria (metrics) for subsequent evaluation and analysis.

One of the available ways to improve the user qualities of products and increase the professional level of employees is the use of usability guidelines (usability guidelines, style guidelines, interface specifications, rules, etc.)

Usability guidelines- a document describing the rules for applying both general and individual, specific interface elements. Formation and verification of compliance with usability guidelines is a technique that allows usability of a site or software to be increased, whose tasks are typical or reducible to typical. Guidelines are also used to standardize and provide some common acceptable level of quality. The guideline contains rules - “heuristics”, often worked out empirically - which are followed when developing a site. These rules can apply to both very small, separate interface elements, and large parts of the interaction.

As a rule, heuristics are formulated so that for each rule it can be said whether it is “supported” in the interface or “broken” (check list), avoiding subjective assessments.

Advantages

The method has a number of advantages:

1. It does not require additional costs.
   Implementation and testing using the checklist does not require additional costs, as in usability testing involving real users or other works using the UCD method.
2. Easy to implement.
   Application of usability guidelines does not require changes to existing development processes and high training and implementation costs.
3. Quickly "vaccinated."
   After several projects, when usability guidelines will be adopted as a corporate standard, the rules described in the guideline will be executed unconsciously (without looking at the document). This is similar to how programmers, after several projects, stop thinking about the rules of Hungarian notation (variable naming convention)
4. Shows specific interface problems and describes solutions.
   Thanks to the guideline, you get a specific description of what problems the interface has and clear instructions for resolving them.
5. Raises the overall "bar" of quality.
   The dependence of the quality of the interface and the usability of the product on the quality of work of specific employees is reduced. If earlier it could be said that someone is doing more accurately, with fewer mistakes, and someone is worse. Now, some acceptable level of quality is achieved by all. In addition, the guideline contributes to the rapid achievement of this level among new employees.
6. It does not require special knowledge for testing.
   For testing on the checklist, no special training is needed. The list testing process is a compliance check.

disadvantages

To be objective, it is worth mentioning some of the shortcomings, which, however, can be called shortcomings conditionally.

1. Incomplete content.
   Each product has its own characteristics and often its own interface elements. Creating a universal guideline will fail.
2. Guideline does not solve interaction problems.
   In the rules it is almost impossible to take into account the context of use, features of users and their tasks. These issues are resolved in each case in their own way. The list only guarantees the absence of gross errors.
3. To compile the checklists will require some time and patience, experience, studying the best practices, and some knowledge in usability, of course.
   You can involve experts in such work. An audit of your guideline by an expert will not be superfluous.

Content

As a basis for my guideline, I used the checklist of Vlad Golovach and the Research Based Web-design and Usability guidelines, which I supplemented with the rules derived from the practice of web development of the company in which I worked. In drawing up your guideline, you can use both the lists I mentioned and mine. Currently it contains rules (heuristics), grouped by the following elements:

• Forms
• Buttons
• Input fields
• Lists
• System Messages and Error Handling
• Checkboxes and Switches
• Text
• Step-by-step actions (master)
• Captcha

The list can be supplemented with rules for whole elements of interaction. For example, I added rules for step-by-step actions (wizards) and captcha.

Consider a few rules. For example: “1.1 Required fields are marked with an asterisk in front of their name. The form has an explanation about the designation of required fields. ”


This rule was added because of the hypothesis that reading from left to right, the user will quickly see the required fields and fill them immediately. But there are exceptions to the rules. For this, it consists in the fact that for an authorization form, fields are not marked with an asterisk. For forms where all fields are required, you can not indicate each, but you must write that all fields are required. This is best done on top of the form, above all the fields.

Or another rule: “1.2 The names of the fields are aligned on the right side. The distance from the name to the field is the same for all fields. ” This rule is deduced on the basis that right alignment avoids the crest from the text. Also, long distances (if the alignment was on the left side) greatly complicate the association of the field name with the field itself. It is not uncommon to have to check the correctness of filling several times.


Another rule: “3.3 For the input fields of quantitative characteristics (length, weight, height, speed, distance, size, etc.), units of measurement must be specified.” As you understand, the rule allows you to get rid of the confusion that would arise if the units of measurement were not signed.

Guideline Tips

1. In each case, it is necessary to develop your own checklist, since it must take into account the specifics of the software being developed and the capabilities of the development tools.
2. Make absolute rules. That is, the rules should not contain subjective requirements (such as “navigation should be done well”). Absolute rules unify the interface.
3. Make rules for disagreement and discrepancy. When there are two equivalent options for an interface solution, make any of them the rule. This at least guarantees interface consistency.
   Usability tests are carried out all over the world, as a result of which the most ergonomic solutions are determined. Based on the results of these tests, recommendations are made for resolving disagreements. As an example, we can cite the arrangement of the Ok and Cancel buttons in various operating systems. If in the dialog boxes of Windows OS the button “Cancel” is located on the far right (a canceling action), then on MacOS it is the opposite “OK” button (confirming action). By following the links, you can read the details of these studies.. In my opinion, the most important thing is not the search for evidence of how to arrange the two buttons, but the guarantee that this location will be the same in different places on the interface.
4. Keep time-tested, best solutions as rules.
   In the process, you get feedback from users or customers, your support team receives tickets, or maybe you just study competitors' products - everywhere you find successful interface solutions. Implementing such solutions, describe them in the guideline.
   I recommend reading the article “ Placing the Forward and Back Buttons in Forms ”

Implementation

We turn to a very important issue - the introduction of guidelines in the workflow. The first thing to do is to “infect” quality and usability management. Without the support of the leadership, any, even the best idea, freezes and is not brought to the end. Tell us about the positive contribution of usability. For example, for software development it is:

• Reduce development costs
• Reduce development time
• Lower product support costs
• Reduce product conversion costs

Work on usability guidelines. Using the links from the presentation, you will receive, perhaps, the largest collection of guidelines. Learn them. Take what is right for you.

Discuss the list of rules with department heads and colleagues. Put the document in the public domain (for example, in the local wiki). Let everyone have the opportunity to familiarize themselves, discuss and share their thoughts. Allow the guideline to twist out. Based on the results of communication, make adjustments. Do not rush to make absolutely all the wishes and proposed rules.

The most important and difficult thing to do next is to ensure that the created document becomes an internal standard. Only in this case, we can talk about systematic quality improvement. The standard must be read and observed by all company employees involved in creating value for the client.

Create the usability category in your bug tracking system. Tell your colleagues about the innovations. Explain that usability bugs are just as important as everyone else. In the 1C company, for example, whole builds come out after fixing only usability bugs.

Review existing ones periodically and add new rules (kaizen). Make changes to the guideline along with changes in the interface and new modifications of your software.

Guidelines for software development market leaders

Among the companies creating and supporting their usability guidelines are such well-known and large companies as: SAP, Microsoft, Apple, Sun, Oracle, Nokia.

I got the first point of view on style guides in Alan Cooper's book, A Mental Hospital in the Hands of Patients.and it lies in the fact that large companies force developers to use them. Microsoft and Apple are promoting guides on interface styles, extolling their power and benefits, and at first glance it might seem that these companies are the most competent source of such information. Both platform creators use a covert form of coercion, trying to force manufacturers to adhere to the standard. An independent software developer, who does not follow the recommendations of the style guide, will not be able to declare "platform compatibility", depriving his product of an important plus in terms of marketing. Thus, most companies creating custom applications are ready to follow the recommendations of the platform developer. In the meantime, the platform developers themselves are free to experiment and give way to innovations as they wish.

Another point of view is that the use of guidelines allows you to create interfaces that are ideally compatible with products and services of manufacturers, reduce the number of errors in the created PI for third-party developers.

Following manufacturer’s guidelines makes the interface consistent. For example, a 1C company transfers disk guidelines to its 1C Accounting partners. Microsoft showed


both points of view in its guideline , giving an example of what could happen if their recommendations were not followed.

This guideline provides a series of rules and guidelines for creating the Ribbon Bar.(new concept for the Office 2007 software interface). For example, the most common functions are located in the middle of the bar, then the frequency goes from left to right.

Testing

I will demonstrate testing using the guideline on a live example.



The interface you saw has one screen and one message window. We will analyze them using the guidelines of the guideline.


It can be seen that the rule for the form: “1.2 The names of the fields are aligned on the right side. The distance from the name to the field is the same for all fields ”observed. As a rule: “2.2 Button labels begin with a capital letter. If the inscription consists of several words, then each word begins with a capital letter, except for prepositions. " But “Signatures to interface elements begin with a capital letter and end with a colon” ​​is not respected. The signatures “enter password:” and “confirm password:” begin with a lowercase letter, and must with a capital letter. We are writing a bug in your bug tracking system in the usability category.


What is wrong with this message box? For example, the rule: “2.8 Button of negative action“ Delete ”,“ Erase ”,“ Cancel ”) is always the most right one” is observed. You can’t say the same about the rule: “2.2 Button labels begin with a capital letter. If the inscription consists of several words, then each word begins with a capital letter, except for prepositions. " The cancel button is written with a small letter, although the rule is observed for the OK button.

Additionally

• The book of Matthew Linderman, Jason Freide (from the company of 37 signals) "How to create a visited site and avoid common mistakes"
• Jeff Johnson 's GUI Bloopers 2.0 (on ozon.ru )
• Usability guideline of the author of the article
• Microsoft Ribbons Guidelines
• Apple user experience
• Interface Checklist (Vladislav Golovach, Alexander Belyshkin. Usethics)