How to "Do" UX Design: A Guide to the ISO 9241-210 Standard

Probably the oldest and most widely used process in the usability and UX world comes from an International Organization for Standardization (ISO) standard.

The standard we are talking about is ISO 9241-210, which bears the charming and catchy title “Ergonomics of human-system interaction—Part 210: Human-centered design for interactive systems.”

The standard was first published in 1999. But even today, after more than 20 years, the basic idea of the standard remains the same, and the approach is universally applicable. To be honest, many later approaches build on the basic concepts of this standard. The similarities among the various processes are obvious, so we want to jump into this standard immediately.

The basic idea of this ISO standard is to develop interactive systems (or products or services) that have good usability. To achieve this goal, system users with their needs and requirements are placed in the focus of the development. The goal of the standard is to ensure that with the help of knowledge in ergonomics, human factors, and usability, suitable designs can be created by the reader.

Apart from all the technical terms, it sounds pretty simple. And if we are honest, it is. The charm of human-centered development is that the basic principles are easy to understand. The difficulty is that actually mastering them takes a lot of time. Even with a lot of experience, however, usability and UX design remains a discipline based on exchange and mutual consultation because many solutions are possible, which, by the way, is the situation we love the most.

Human-centered development is a separate procedure you can easily integrate into other processes. Whether the technical development of your system, product, or service is conducted in a waterfall model (linear approach with steps that build on and follow one another) or through agile development, you can integrate a human-centered design process.

The fundamental prerequisite is that the system, product, or service design must be based on a comprehensive understanding of the users, tasks, and working environment. However, theoretical knowledge that can be gained at the desk through research (keyword: desk research) is insufficient. You require the direct involvement of users in the design and development of the solution. You must collect feedback, through various methods, from users regarding the design solutions. This feedback is then incorporated into the revision of the solution. Therefore, considering users’ requirements, a product, system, or service is iteratively created, and the overall UX is optimized.

To enable this approach, ISO 9241-210 assumes that a team with interdisciplinary competencies implements the design. The required competencies vary depending on the system, product, or service. Therefore, for your project and company, you must select which competencies are needed in the specific case. From a high-level view, you can incorporate expertise from different areas into your project. The following perspectives could be helpful:

• Strategic view, for example, business analysis, system analysis, and market analysis
• Development perspective, for example, hardware and software development
• Marketing perspective, for example, marketing and sales
• Design perspective, for example, occupational science and ergonomics, usability, accessibility, product design, and user interface (UI) design
• Expert perspective (e.g., users, experts with knowledge in the application domain)

All these different points of view can help you design a successful system, product, or service. At what point and to what extent you include these viewpoints is up to you. But from a purely formal point of view, you can only have a human-centered design process if you regularly and actively bring the expert perspective—that is, the users’ perspective—into your project. Therefore, this viewpoint is not always a free choice but, as is often the case, a duty.

The human-centered design process includes a total of six steps, with the first and last steps defining the start and end of the process, respectively; an overview is shown in this figure.

Step 1: Plan the Human-Centered Design Process

The first step is to plan the human-centered design process. You must decide how much effort should be put into achieving good usability and UX. The standard provides the following three core questions to orient you:

1. What is the relationship of usability to the purpose and use of the system, product, or service?
2. What risks can result from low usability?
3. In which (economic) environment does the development take place?

However, no further assistance is given in determining the scope. So here you’re on your own with your conclusions.

Once you have determined the scope of human-centered activities, you must plan their content by following these steps:

1. Identifying suitable methods and resources
2. Defining procedures for integrating human-centered development into other development activities
3. Defining responsibilities
4. Defining information and feedback channels
5. Defining milestones
6. Determining the timing of the human-centered design process

With all this information, you can embed the human-centered design process into the overall development process. This step is necessary because usually no finished system, product, or service exists at the end of a human-centered design process, only a “construction manual.” These instructions subsequently accelerate implementation considerably: in the case of waterfall planning, the implementation of large parts of the overall product and, in the case of agile development, the implementation of individual building blocks of the product.

Step 2: Understand and Specify the Context of Use

No system, product, or service is used independently of the organizational, technical, social, or physical environment; it is always part of that environment and is influenced by it.

Therefore, the second step is to analyze the current context of use to determine the future context of use afterward.

A good starting point for understanding the context of use is to look at an existing system or similar systems. Only a few systems, products, or services are entirely new and unique. In most cases, you’ll find that users are already solving the same problem or task differently today, which is where you can start. If you already have a solution on the market, you can also start there.

Examining the current situation helps understand how users solve their tasks currently. This examination allows you to discover the strengths and weaknesses of existing solutions and determine what the future context of use should look like. You need this knowledge for the next step. To ensure that the derived knowledge about the context of use is available for the following steps, ISO 9241-210 recommends preparing a context of use description. To ensure that this description is functional, the following questions should be answered at a minimum:

• Who are the users and the stakeholders?
• What are the characteristics of these users and user groups?
• What are the goals and tasks of these users?
• In which environment will the system be used?

How you document all this information is up to you. Our recommendations for implementing and documenting a context of use analysis can be found in Chapter 9.

Step 3: Specify the User Requirements

Based on the context of use analysis, you know where, by whom, and why your system, product, or service should be used. Now, the next step is a matter of formalizing this knowledge and making it testable. To achieve this goal, formulate user requirements in this step. In our human-centric approach, at this point, you might specify requirements that have little to do with the UI itself but are requirements from the organizational context. From our perspective, a core element of human-centered design is that you’re not developing an app, software, or other application—you’re creating a solution that solves your users’ problems and tasks. If the system, product, or service becomes “bigger” due to the insights gained from context of use analysis, then so be it.

When deriving user requirements, you can consider users on the one hand and other stakeholders on the other. You can derive user requirements from the context of use and other sources. These sources could include, for example, legal or regulatory requirements, standards, or organizational processes.

When you collect these user requirements, you’ll notice that conflicts may exist: Not all requirements from different sources can be met perfectly. Sensible weighting is crucial to find the right design later. This weighting should be done in the users’ interest and include other factors (e.g., economic efficiency).

The list of requirements is not a list that you define once and then remains static. In most cases, you’ll find new, expanded, or more precise user requirements during a project that were not initially considered. As the previous figure showed, the process is iterative. Thus, you may add to this list at any time. To get the most benefit from the user requirements, you should make sure that you observe the following rules when formulating them:

• The user requirements should be auditable. Thus, it should be clear to all parties involved whether a requirement is fulfilled or not.
• Stakeholders should support the user requirements.
• The user requirements should be free of contradictions.

Above all, the absence of contradictions in user requirements is a topic we want to emphasize, as it turns out to be particularly complicated in practice. The fact that you involve different stakeholders in deriving the user requirements means that you’ll encounter situations in which various stakeholders formulate contradicting requirements.

Let’s consider an example: In this example company, discussions arise repeatedly in the development team because of a dispute about a function. One part of the team wants to implement this function, and another part thinks this function is not necessary. In such situations, you must decide which viewpoint you believe. An excellent way to resolve such disagreements is to involve the users. In this way, you can decide afterward which team was “right” or whether perhaps even a completely different idea would be more successful.

Step 4: Producing Design Solutions

Now, since you have a first guess of what makes a good solution, you can start producing design solutions. When discussing human-centered design, this activity is usually not yet about technical development. Instead, the point is to find design solutions in this phase of human-centered design that subsequently enable an evaluation by users and stakeholders. The evaluation is then carried out in the next step—but prepared in this step to the extent that we learn something in the iteration.

To carry out an evaluation, stakeholders and users need a concrete solution to evaluate. Suitable examples include scenarios, pictures of individual UI parts, simulations, or prototypes that help users understand how they would later interact with the system, product, or service. However, these functionalities do not have to be technically realized. It is enough to build everything “in the background” as simply as possible.

For example, if you need a chatbot, you don’t need to program it. Instead, you can put a human in the next room to simulate the chatbot for user feedback.

So, the critical thing with this kind of human-centered design is that you get to a prototype suitable for user testing as quickly, easily, and inexpensively as possible. Why? Because in the next step, you’ll test the prototypes with users and, in most cases, adapt them afterward. The faster, easier, and cheaper you can prototype, the faster you can learn and improve your design solution. As a result, your first prototypes are usually quite simple and become more sophisticated and product-like as you become more confident in the design.

However, an essential step is that you also consult with the later implementers already in the development process. You can save yourself—and them—a lot of unnecessary work if you enter into communication at an early stage. This suggestion applies not only to the final design solution but also to the intermediate steps.

Step 5: Evaluating the Design

The final substantive step of the human-centered design process is evaluating the design solution. This evaluation should be performed by and with users in most cases. The reason: All so-called “expert evaluations” (i.e., without users) can give you feedback on individual aspects, but usually not on acceptance and not sufficiently on whether the solution fits the users’ tasks. However, both elements are crucial for the later success of your system, product, or service. Only in exceptional cases should you deviate from this rule. Suitable exceptional cases could be when you want to identify serious usability problems early on. Expert assessments are usually suitable for this purpose.

When you evaluate design according to ISO 9241-210, you’ll focus on the following activities:

• Getting new information about user requirements
• Understanding the strengths and weaknesses of the design solution
• Checking whether user requirements have been met
• Comparing different variants with each other
• Enabling a later comparison with a reference value (benchmarking)

Various methods are available for evaluating the design solution that are not further detailed in the standard. Most of these methods presented include an evaluation by users. However, we’ll also explore expert methods without user involvement. In addition, some methods perform an evaluation not selectively but over an extended period instead.

The goal of the evaluation, according to ISO 9241-210, is to understand if something needs to be changed and, if so, guide us towards what needs to be changed and in what direction. So, the evaluation is the step where you’ll decide if you’re done with your design solution or need to go back into the process. The process can be ended if the following conditions are met:

• No new user requirements have emerged.
• Your design solution matches all known user requirements.
• The overall usability and UX are good enough.

Conclusion

The human-centered design process, according to ISO 9241-210, represents something like the original human-centered design model. In one form or another, you’ll always find the elements or process steps mentioned in this post in other processes and consider them repeatedly. Many of the processes we are about to show are slightly different representations or place different emphases but have the same core.

Editor’s note: This post has been adapted from a section of the book Usability and User Experience Design: The Comprehensive Guide to Data-Driven UX Design by Benjamin Franz and Michaela Kauer-Franz.