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 1: Joint Design Teams

From SKYbrary Wiki

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

Summary

Build joint design teams and do not treat HF/E as a mandatory add-on

Principle 1: Joint Design Teams
Principle 1: Joint Design Teams Icon: EUROCONTROL © (All rights reserved)

HF/E is often seen as something separate to design. Organisational and methodical conditions even reinforce this fragmentation

Make HF/E an integral part of the design process instead of a mandatory add-on and let engineering and HF/E act as a joint team

Although HF/E claims to be design driven and strives for an active role in ATM system design, HF/E is often treated as something separate. Usually, there are distinct HF/E departments, HF/E processes, HF/E assessments, and even separate HF/E requirements as if HF/E is just an addendum to the regular design work. This separation is maintained in the whole aviation industry but especially in ATC. Other industries do not pursue this separation between design and HF/E. Instead, HF/E experts are employed in the relevant unit, such as cockpit design at a car manufacturer. In this setting, HF/E experts, engineers and designers meet as equals in an interdisciplinary team.

Why did HF/E integration evolve differently in ATC?

Probably because a close linkage of HF/E to safety has a long tradition. In a world where human error is perceived to be the main source of incidents, it makes perfect sense to maintain a separate organisational capacity that exclusively deals with this phenomenon. In this role, HF/E has the expertise to explain human error and to develop adequate prevention strategies for new systems and procedures. HF/E’s role is to assess a given design with respect to the likelihood of human error occurring and to assess if potential human error may undermine safety in later operations. This perspective, however, is not in line with the idea of Safety-II, as it still understands safety as the absence of incidents. In consequence, HF/E is often reduced to a simple hazard analysis, with a focus on humans instead of technical components. Design units are likely to adopt this perspective and perceive HF/E as an additional item on the to-do list in order to receive HF/E blessing. However, one cannot expect others to accept HF/E as an integral part of design as long as the self-concept of HF/E in ATM remains caught in this perspective.

HF/E should rethink its role and clarify its nature in ATM: Does it actually want to be an integral part of design or is the task of HF/E more or less the evaluation of predefined technical descriptions? HF/E at least claims to take an action view and to be an active part of system design. A clear commitment to design is indispensable to be recognised as a key player for usable system design by other experts and departments. Existing methods even facilitate the asymmetry between analysis and design. This is because HF/E methods rely very much on already finished “products” that can be evaluated in situ (in operation or at least in simulation environments). Essentially, HF/E methods collect either user feedback in one form or another, or they measure users’ (involuntary) responses. Examples of the former are questionnaires, subjective workload assessments or scoring situation awareness. Examples of the latter are eye tracking, eye blink frequency or heartbeat irregularity.

The problem, of course, is that for a long time during a new development, there is no finished product to evaluate. Rather there is a great need for input in terms of requirements and implementation ideas long before a first prototype exists. HF/E falls short on methods that can be used before a prototype is available.

This limitation has a couple of implications:

  • First, HF/E input is often handled and perceived as an afterthought. That means HF/E requirements or considerations are simply placed on top of existing requirements and concepts. This leads to additional effort for integration, or it might not be possible to integrate them at all. Within an organisation, HF therefore is seen more as a hindrance than as a contributor.
  • Second, even if there are HF activities taking place early during a project, there is no defined interface between them and the typical engineering design and/or project management processes. This is true on the organisational level and the methodical level. Teams are not integrated and work separately with their own tools and, more importantly, worldviews and jargons.
  • Third, HF requirements themselves are not usable from an engineering perspective. Most methods have a lot of explanatory power but lack the transfer into clear design implications. Requirements need to be (among many other qualities) specific and verifiable. Typically, HF requirements are not specific due to their link to HF/E concepts instead of engineering entities and are not verifiable either, or are only verifiable with the finished product. There are practically no modelling or simulation tools around that allow the checking of the impact on workload or situation awareness of competing concepts before implementation.
Principle 1 Icon: EUROCONTROL © (All rights reserved)


It is the task of HF/E science to overcome those methodical limitations. Salmon (2016) names several potential improvements for HF/E methods. Two proposals among others are that prospective ergonomic methods should, firstly, be based on system thinking and, secondly, directly inform design. He also points out that there remains a paucity of reliability and validity evidence for ergonomic methods: The extent to which some ergonomic methods actually work and thus are fit for purpose remains unclear. Shorrock & Williams (2016) identified accessibility constraints, usability constraints and contextual constraints as limiting factors for HF/E methods. They suggest a close linkage of HF/E methods to the usercentred design process in order to make methods fit for purpose. ANSPs, as practitioners, on the other hand, need to make sure that HF/E is incorporated into the organisation and ATM development processes. Not as a mandatory add-on, but as an integral part of the overall design proposition.

Nevertheless, the question remains how HF/E could contribute if analysis and evaluation alone are not sufficient in ATM design. What could be a significant HF contribution from an engineering perspective? This whitepaper suggests promoting a coherent user-centred design rationale as a distinct HF product. Principle 2 will illustrate this idea in more detail.


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