From the survey at the end of the previous article, I found out 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 describe 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 standard 9241-210

If you ask a Human-Centered Design specialist about the main steps within the HCD, you are likely to draw something like this:


This diagram is the cornerstone of the ISO 9241-210 standard. It describes the steps involved in designing an interactive system as part of an HCD.

Before dealing with each of the steps, let's dwell on the principles of HCD described in the standard.

HCD Principles

The ISO 9241-210 standard describes 6 principles to consider when creating an HCD product:

1. Design should be based on an accurate definition of users, their tasks and environment. That is, we need to know who our users are, what tasks they will solve and in what conditions. Also here should pay attention to the phrase "based on an accurate definition." By this, it is understood that within the framework of HCD, design is carried out not on the basis of the assumptions of the marketing or design departments, but on the basis of data obtained as a result of research. I will talk about what types of studies are and how to conduct them in one of the following articles;
2. Users must be involved in design and development. Involving users in the development process allows you to get the necessary information about the context of use, tasks and how much 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 of the design decisions will turn out to be the most adequate. Accordingly, such iterations should be included both in the project schedule and in the budget;
5. A little more than just usability. In the original, it sounds like “The design addresses the whole user experience”. In GOST it is translated as “accounting for user experience”, which, in my opinion, distorts the meaning of the phrase. The point is to focus not only on ease of use, but also take into account aspects such as job satisfaction, lack of monotony, etc. If someone is able to propose a suitable Russian analogue for this principle, I will gladly include it in the article ;
6. The team must be multidisciplinary. Theoretically, everything is simple here - the wider the general outlook of the development team, the more aspects of 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 problems, and different value systems (for example, what is more important than functionality or design). Accordingly, the possibility of such disagreements should be foreseen and a settlement strategy should be chosen in advance.

Now that we’ve figured out the basic principles, let's move on to the steps in the HCD process.

HCD Planning

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

1. Identify suitable methods and resources needed. I plan to devote a separate article to the methodology for selecting 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 to avoid situations when you wrote an excellent report on Usability, but designers and developers do not use it, since it is already difficult / expensive to make the changes you proposed;
3. Identification of responsible. It is especially important if the team or company used to be engaged in HCD. Otherwise, the process will be left to chance;
4. Identification of communication channels and conflict resolution methods. You wrote a cool Usability report, the project is still in the design stage. The price of the changes is relatively low, but the designers are not aware of the existence of your report. Or worse. Designers have read your report, but consider your suggestions erroneous. There must be a procedure for resolving such contradictions;
5. The time frame for the individual stages of the HCD and their integration into the overall development plan should be consistent. This includes the timing of iterations, periods for making changes to the project, etc.

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

Usage Context Specification

First of all, the context of use means the totality of the 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 the following actions as part of the specification of the context of use:

1. Identify the main user groups and stakeholders. In the future, these groups will be sources of requirements for our project;
2. Define the goals and objectives of the above users and stakeholders. Knowing the goals will help us in describing the product requirements. As far as tasks are concerned, we will be primarily interested in those whose characteristics affect usability or accessability (for example, 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 is defined, we can develop product requirements based on this context.

Requirements specification

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

1. Describe product requirements. The 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 the internal contradictions in the requirements;
   • Relevant and updated throughout 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 restrictions 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 graphics engine instead of using existing ones.

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

Design / Design Interaction

ISO 9241-210 recommends that the following actions be included as part of this step:

1. Design user tasks, user and system interactions, as well as the interface, so that they meet the requirements formulated in the previous phase. At the same time, we are not just talking about adding certain functions, but proceed from the fact that the user has certain goals. To achieve these goals, the user performs certain actions. For example, the user accountant does not want to just perform abstract arithmetic operations. He wants to finish the tax report as quickly as possible in order to avoid problems with management.
2. Detail design decisions. Here it is recommended to develop several parallel solutions at once in order to be able to test them on users. It is also recommended to lay time for several design iterations - this will allow you to develop a more holistic solution.
3. Use user feedback to improve design decisions;
4. Deliver design solutions to those who will be involved 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 is workable for real users.

Conformity assessment

The compliance check has the following objectives:

1. Get new user information. During the design process, you have new clarifying questions. You received an answer to some of them, and partly answered based on your assumptions. As part of this step, you can test your assumptions in practice;
2. Get feedback on design weaknesses and strengths. This will prioritize the next iteration;
3. Set criteria regarding which you will compare the current and next versions of the project.

To achieve these goals, the standard recommends the following:

1. Evaluation of solutions based on tests with user participation. For example, you invite users and ask them to perform certain actions in your program;
2. Assessment 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-term monitoring. Analysis of critical situations, calls to support, etc.

After evaluating your product, it's time to choose. If you find significant flaws and the budget allows it, then you return to one of the previous stages. If everything is fine, or you are running out of money, you are releasing a product.

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

Application of ISO 9241-210

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

Waterfall model

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


How can we apply the HCD approach within this model?

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

As part of the development, we can include the design phase from the HCD approach. In addition, we may partially include here the 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 with a dashed line, because it assumes an iterative development process, which may contradict the vision of the development team.

Also , the compliance assessment phase can extend to the assessment and support phases of the Waterfall model.


I suppose that the main problem that you will encounter when implementing the HCD approach in the framework of the Waterfall model will be the lack of iterations in the framework of the model. This problem can be mitigated by looping the Waterfall model. Another question is how much this loop is related to the preferences and / or strategic goals of your leadership.

Scrum model

More flexible model. In addition, iterativeness was originally laid in it.

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 specification of requirements can serve as a source of information for the backlog of the project . Also, studies within the framework of HCD (for example, interviews, polls, diary studies and others) can form the basis of the Sprint Story.

Assessment of compliance with the requirements may, on the one hand, help to choose the most priority tasks for the next sprint ; on the other, evaluate the results at the end of the current sprint .

The design phase from the HCD approach, respectively, can be implemented as part of the current sprint .

In conclusion

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

In the coming year or two, the ISO 9241-220 standard will be released, which will describe each of the HCD phases in more detail. While it is not available to the general public, however, its text has come across to me a couple of times on the Internet. 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, time frame, relative complexity of the project, etc.).