From the survey at the end of the previous article, I learned that readers are interested in all three of the proposed aspects of Human-Centered Design (hereinafter - HCD):

• Standards
• Methodology,
• Implementation.

In this article I will explain how to use the ISO 9241-210 standard for planning and implementing the HCD approach . I will also show how HCD can complement the two most commonly used development models: Scrum and Waterfall .

ISO 9241-210 standard

If you ask a Human-Centered Design specialist about the main steps in the HCD framework, you will most likely draw something like this:


This scheme is the cornerstone of ISO 9241-210. It describes the design steps for an interactive system within the HCD.
')
Before dealing with each of the stages, let's focus on the principles of HCD, described in the standard.

HCD principles

The ISO 9241-210 standard describes 6 principles to consider when creating a product within the HCD framework:

1. Design should be based on the precise definition of users, their tasks and the environment. That is, we need to know who our users are, what tasks they will solve and in what conditions. Also here you should pay attention to the phrase "based on a precise definition." This means that within the HCD framework, the design is carried out not on the assumptions of the marketing or design departments, but on the basis of the data obtained as a result of the research. I will talk about the types of research and how to conduct them in one of the following articles;
2. Users should be involved in design and development. Involving users in the development process allows you to get the necessary information about the context of use, the tasks and how well the product will be accepted by users after the release;
3. Design should be based on user feedback. Thus, we minimize the risks that the future product will not meet the requirements of users and / or organizations;
4. The process must be iterative. It is not possible to predict in advance which design decisions will be the most appropriate. Accordingly, such iterations should be included both in the project schedule and in the budget;
5. Slightly more than usability. In the original, it sounds like "The design addresses the whole user experience". In GOST, this is translated as “accounting of user experience”, which, in my opinion, distorts the meaning of the phrase. The idea is to focus not only on ease of use, but also to take into account such aspects as job satisfaction, lack of monotony, etc. If someone is able to offer a suitable Russian equivalent for this principle, I will gladly include it in the article ;
6. The team must be multidisciplinary. Theoretically, everything is simple here - the broader the overall horizons of the development team, the more aspects of the HCD will be taken into account. In practice, it should be borne in mind that representatives of different professions may have different approaches to solving the same tasks, and different value systems (for example, which is more important than functionality or design). Accordingly, the possibility of such disagreements should be foreseen and pre-selected settlement strategies.

Now that we’ve dealt with the fundamentals, let's move on to the steps in the HCD process.

HCD Planning

As part of HCD planning, the ISO 9241-210 standard proposes the following actions:

1. Identify suitable methods and required resources. I plan to devote a separate article to the selection of suitable methods;
2. Determining how the above methods will be integrated with other development processes. HCD should not hang in the air. This will help avoid situations where you have written an excellent report on Usability, but the designers and developers do not use it, since it is already difficult / expensive to make the proposed changes to the project;
3. Definition of responsible. It is especially important if the team or company used to engage in HCD. Otherwise, the process will be left to chance;
4. Identification of communication channels and methods for resolving contradictions. You wrote a cool report on usability, the project is still in the design stage. The cost of change is relatively low, but designers are not aware of the existence of your report. Or worse. Designers read your report, but they think your suggestions are wrong. There should be a procedure for resolving such contradictions;
5. The timeframes of the individual HCD stages and their integration into the overall development plan should be agreed. This includes the timing of iterations, the periods for making changes to the project, etc.

After all the necessary stages have been planned, we can proceed to the specification of the context of use.

Context specification

First of all, the context of use means a set of characteristics of users, their tasks, as well as the organizational, technical and physical environment in which this or that product is used or will be used.

Accordingly, ISO 9241-210 recommends that the following actions be performed within the context of use specification:

1. Identify the main user groups and stakeholders. In the future, these groups will be sources of requirements for our project;
2. Identify the goals and objectives of the above users and stakeholders. Knowledge of goals will help us in describing product requirements. As for the tasks, we will be primarily interested in those whose characteristics affect usability or accessability (for example, the frequency of execution, duration, danger, etc.), as well as those that will help to better understand the context of use (for example, lighting conditions );
3. Define the technical, organizational and physical environment. It will also allow us to better understand the context of use and provide a basis for describing product requirements.

Once the context has been defined, we can develop product requirements based on that context.

Requirements specification

As part of the requirements specification process, the standard recommends the following actions:

1. Describe product requirements. Requirements should be described based on the intended context of use. Also, when creating a list of requirements, various standards, requirements of business and supervisory organizations can be used.
2. Resolve contradictions between different requirements. In doing so, document the rationale for the decisions made. This is especially true in large organizations with high staff turnover;
3. Verify the quality of the stated requirements. Requirements must be
   • Formulated in such a way that in the future the product can be tested for compliance with these requirements;
   • Agreed with all interested parties;
   • Holistic. I hope that you have already resolved all internal contradictions in the requirements;
   • Actual and updated during the life of the project. Outdated requirements are like an outdated antivirus - they give a deceptive sense of security.

An interesting question is whether it is necessary to include technical limitations in the list of requirements. Here you can consider two options:

1. We use the HCD approach to refine an existing product. In this case, it is obvious that technical limitations should be reflected in the list of requirements;
2. We are developing a new product. In this case, we are not yet tied to a specific platform. Therefore, here we can customize the platform to the requirements of the design. For example, we may decide to write our own graphic engine, instead of using existing ones.

After the requirements are formulated, it's time to move on to design.

Interaction Design / Design

The ISO 9241-210 standard recommends the inclusion of the following actions in this phase:

1. Design user tasks, user and system interaction, and interface, so that they meet the requirements formulated during the previous phase. At the same time, we are not just talking about adding certain functions, but we presume that the user has certain goals. To achieve these goals, the user performs certain actions. For example, a user accountant does not want to simply perform abstract arithmetic operations. He wants to complete a tax report as quickly as possible in order to avoid problems with management.
2. Detail design solutions. Here it is recommended to develop several parallel solutions at once in order to be able to check them on users. It is also recommended to lay the time for several design iterations - this will allow you to work out a more holistic solution.
3. Use feedback from users to improve design solutions;
4. Communicate design decisions to those who will be engaged in the development / implementation. Otherwise, the final product will not be complete, even if it was designed as such.

At the end of this stage, we have a holistic and detailed solution in terms of the interaction of the system and the user. It's time to evaluate how much our solution works for real users.

Conformity assessment

Compliance testing has the following objectives:

1. Get new user information. During the design process you had new clarifying questions. You received a reply to a part of them, answered to a part proceeding from your assumptions. At this stage, you can test your assumptions in practice;
2. Get feedback on design strengths and weaknesses. This will prioritize the next iteration;
3. Set the criteria for which you will compare the current and next version of the project.

To achieve these goals, the standard recommends the following actions:

1. Evaluation of solutions based on tests with the participation of users. For example, you invite users and ask them to perform certain actions in your program;
2. Evaluation of decisions based on expert opinion. You invite an expert and he evaluates your product based on his own experience and generally accepted practices. A relatively cheap solution, but the most critical problems are likely to be missed;
3. Long monitoring. Analysis of critical situations, calls to the support service, etc.

After evaluating your product, it's time to choose. If you find significant shortcomings and the budget allows it, then you return to one of the previous stages. If everything is good, or you run out of money, you release a product.

It was a theory, but how to implement this approach, for example, within the framework of Waterfall or Scrum models?

ISO 9241-210 application

In this article, I assume that the reader is familiar with the models of Waterfall and Scrum, so I will not spend much time describing the features of each of the approaches.

Waterfall model

Below you can see a graphical representation of the Waterfall model. We start with the formulation of requirements, then we develop a solution according to the requirements. We implement the solution, evaluate it and correct errors / omissions.


How can we apply the HCD approach within this model?

For example, as part of the description of requirements , we can follow the phases of the specification of the context of use and the specification of requirements from the HCD approach.

As part of the development, we can include a design phase from the HCD approach. In addition, we may partially include a compliance assessment phase . This will allow us to develop a more holistic solution and avoid “childhood diseases”. In the diagram below, I showed this option dotted out, because it involves the iteration of the development process, which may be contrary to the vision of the development team.

Also , the compliance assessment phase can extend to the assessment and support steps from the Waterfall model.


I will assume that the main problem that you will encounter when implementing the HCD approach within the Waterfall model will be the lack of iterations within the model. This problem can be leveled by looping the Waterfall model. Another question is how does this looping correlate with the preferences and / or strategic goals of your leadership.

Scrum model

More flexible model. In addition, it originally laid iterative.

How can the HCD approach be integrated into this model?

First of all, the results of the phases of the specification of the context of use and the specification of requirements can serve as a source of information for the project backlog . Also studies within the HCD framework (for example, interviews, surveys, diary studies, and others) can form the basis of the Sprint Story history .

Compliance assessment may, on the one hand, help you select the highest priority tasks for the next sprint ; on the other hand, evaluate the results at the end of the current sprint .

The design phase of the HCD approach, respectively, can be implemented within the current sprint .

As a conclusion

As you can see, the ISO 9241-210 standard provides the basis for planning and managing processes within the HCD framework. At the same time, it is quite abstract and can be used in almost any situation.

In the next year or two, the ISO 9241-220 standard will be released, which will describe each of the HCD phases in more detail. So far, it is not available to the general public, but its text came across to me on the Internet a couple of times. If one of my colleagues finds it and sends me a link, I will be very grateful.

In the next article, I plan to describe an approach that allows you to choose one or another HCD method depending on the current situation (budget, timeframe, relative complexity of the project, etc.).