If you wish to contribute or participate in the discussions about articles you are invited to join SKYbrary as a registered user

 Actions

Toolkit

Human Factors Integration in ATM System Design/Principle 3: User-Centred Design Process

From SKYbrary Wiki

< Toolkit:Human Factors Integration in ATM System Design
Toolkit Navigation

Summary

Strive for a short, iterative user-centred design process

Complexity in ATM makes it impossible to get a system design right the first time. Linear design processes make it more difficult to revise misconceptions and to implement changes.

Principle 3: User-Centred Design Process
Principle 3: User-Centred Design Process Icon: EUROCONTROL © (All rights reserved)

Strive for a short, iterative user-centred design process that gives you room to adapt. Integrate this approach into your existing processes, even though they are supposedly linear.

The previous principle suggested a user-centred design rationale as a specific HF/E outcome within ATM design. This chapter proposes the user-centred design process as a suitable approach for its development.

Typically, ATM deals with particularly long-term strategies and plans. There are system roadmaps laid out for years, sometimes decades. These are necessarily linear in nature, for example, which feature comes after which enabler. When this is broken down into the implementation projects, the linearity is kept. The typical project management plan deals with a string of milestones with few parallel phases. This is supposed to keep the risks low, as there are only few interactions between the phases. The archetypical product/software development process, the waterfall model, follows the same pattern.

Nevertheless, there are some major drawbacks. Most of the time, the product has to be fully specified in order to commence the implementation phase. The implementation phase ends with an almost complete product, which is then tested against the requirements. After that, there will be user tests (at best) before training and introduction. Unfortunately, experience shows again and again that the specification is never fully right and complete. Sometimes it was built on wrong premises. Experience also shows that truly fixing this is staggeringly expensive and in the worst case impossible (cf. Alexander & Albin, 1999). The product is already there and was designed and built with a lot of effort, after all.

In complex systems such as ATM, it is impossible to identify every possible situation and circumstance upfront. Thus, a certain amount of information is necessarily overlooked during the concept and planning phases and often during development. The surprises – unexpected situations, unexpected behaviours, unexpected side effects and interrelations – only come to the surface during transition and operational use. With linear approaches, it is almost impossible to react then, because the requirements and implementation phase are long over. Flexibility is lost very early when complexity is still low.

HF/E acknowledges this reality of complexity and emergence. That is why established HF/E processes such as user-centred design (DIN EN ISO 9241-210, 2010) are highly iterative. Since you cannot know everything in the beginning, you base the design on what you know, implement it via rapid prototyping, and evaluate it. Do this several times until you have learned enough to be confident that there are only minor surprises left. At its core, it is a flexible, highly iterative process. It consists of four main phases as shown in the figure below, which are run through repeatedly until the product satisfies the needs.

At first glance, a linear project management and an iterative design might seem mutually exclusive. Yet, there is no fundamental incompatibility. Several iterations can be planned into the classical project phases. However, this has to be done during the proposal phase. Otherwise, the necessary resources (such as software programmers for early concept prototypes) will not be available in the early project phases.

User-centred design should not be confused with agile methods of software development, such as SCRUM. Some characteristics are similar (strong focus on iterations and user involvement), others are not. A core element of most agile methods is to quickly implement isolated features of the software to operationalise and review them with users. On the surface, this sound like the user-centred design idea, but there is no mechanism to ensure the big picture, with all features combined, actually makes sense in the end. The HF/E design rationale and concepts have to be defined to a degree of certainty before the actual implementation of features starts. The similarities, however, make it easy to reconcile user-centred design and agile methods if the respective strengths and weaknesses are acknowledged.

User-Centred Design Process According to DIN EN ISO 9241-210

Principle 3: User-Centred Design Process
User-Centred Design Process According to DIN EN ISO 9241-210


Source: White Paper on Human Factors Integration in ATM System Design, EUROCONTROL, 2019

The White Paper is available on Bookshelf here: White Paper on Human Factors Integration in ATM System Design