If you wish to contribute or participate in the discussions about articles you are invited to join SKYbrary as a registered user
Human Factors Integration in ATM System Design/Next Steps
From SKYbrary Wiki
This white paper takes an optimistic stance on the role and prospects of HF/E integration into system design in ATM. The application of the principles may serve as a starting point to tackle current challenges and close the gap. It is up to the reader to determine how exactly those principles should be implemented. Nevertheless, it is possible to give some general suggestions for ANSPs as well as for the scientific community.
Suggestions for ANSPs
All the European ANSPs face the same fundamental challenge of how to cope with increasing traffic with fewer people in an ever more competitive environment. Operational complexity is reaching new heights and so are the promises of technology and automation. In the process of the ensuing changes, safety must not be compromised.
The nine principles offer some answers to the question of how to approach this. The key message is that HF/E can contribute significantly under the right circumstances. Four implications for immediate action are suggested for ANSPs:
- 1. The ANSPs have to take the idea of safety by design seriously.
This is a logical consequence of Safety-II and System thinking. The makeup of each ANSP as a socio-technical system enables or prevents adaptations necessary for an acceptable performance under ever changing conditions. To contribute actively to system design, HF/E departments have to change their roles from risk mitigators (for human error) to safety designers. They need to change from being critics of others to becoming designers of tasks, roles, circumstances, and technology, themselves. This implies becoming more involved in decisions on different levels, from strategy to concrete engineering. With this comes much bigger responsibility and the potential for contributing by providing a cohesive user-centred design rationale, which is missing today. HF/E departments of ANSPs need to question whether they actually want to become a decisive, integral part of ATM development or just evaluate predefined technical descriptions. A clear commitment to design is indispensable.
- 2. The interface between HF/E and systems engineering needs to be defined by elaborating ways of cooperation and the exact division of labour.
There could still be a separate HF/E department but with full integration of its members on a project-based level. Another possibility is merging HF/E together with other areas into one or more new departments that are responsible for development on different abstraction levels, such as concept development and interface development. Whatever the organisational structure, the tasks of problem-setting and problemsolving need to be adequately addressed. Knowledge transfer between the individual HF/E experts has to be ensured. The blurring of traditional HF/E and engineering is desirable when working on concrete tasks, but overall the unique worldview of HF/E must not get lost and problem-setting should be established on a regular basis to synchronise among different projects and propositions.
- 3. A successful integration of HF/E in design is difficult with today’s processes. They need to change, as does the attitude that comes with them. As long as there is a technological core and then the mitigation of some Human Factors along the way, it will not be possible. User-centred design has to become the standard practice.
It changes the perspective on design as it puts the users and their needs in the focus. The question becomes what the design projects are actually trying to achieve on a system level, with the technological means as a way to get there. This requires a different approach to project management. Space has to be created for various iterations and the phases and milestones have to be planned more flexibly. Users have to be available throughout for evaluations, which is a wise investment but not easy to achieve when only a few controllers are available.
- 4. Fourthly, the systems approach should be utilised for strategic management decisions and the assessment of new technologies.
HF/E is able to contribute a deep understanding of current operations by identifying bottlenecks and mechanisms, e.g. for capacity growth, by analysing the entire socio-technical system. This may happen independently of specific technologies. Based on that, a purpose-orientated perspective on technology can be introduced, which helps to select the alternative out of many possibilities that fits operational conditions best. For this, HF/E needs to be fit to participate in strategic decisions and to take responsibility for a smooth human-machineintegration; not just to ensure an improvement in system performance, but also to actively manage human well-being so that the resulting work and environment will keep an attractive and meaningful character even with more automation
Suggestions for the Scientific Community
Practice and research are closely related in HF/E. It is the latter’s task to provide new insights, data, and methods to inform design in practice in order to optimise the overall system performance and human well-being. There have been numerous publications bemoaning the theorypractice gap (e.g. Chung & Shorrock, 2011; Buckle, 2011; Salmon, 2016; Shorrock & Williams, 2016). This whitepaper further verifies this gap and suggests six implications for the scientific community based on the previously described principles.
- 1. Even though HF/E claims to be design driven, there is a lack of adequate design methods.
Traditionally, there is a strong focus on fundamental research and associated methods for analysis but only little is available that actually help practitioners to design workplaces in complex environments. User-centred design forms a solid foundation but there is a lack of proven methods to actually flesh out two of its four phases, namely requirements specification and the production of design solutions. Since these are part of any product development process and thus well established, HF/E has to either provide its own interpretation that can be adopted by the other stakeholders in a design project or specify how the existing ways need to be complemented. Additionally, the transfer between different stages within a user-centred design does not work seamlessly. The difficulty often is not to outline a fist design but to maintain a coherent user-centred design rationale through the whole development. Therefore, the transfer between the phases of a usercentred development is by far more challenging than the actual work within each phase. Methods are needed that help to commute between these phases and bring them in coherence with each other. For example, this includes the question how to convert the results of a task analysis (as part of a context of use analysis) into subsequent user requirements.
- 2. Especially delicate is the question of how to integrate users in a sensible manner.
General approaches like questionnaires, interviews or observations might be appropriate but are not structurally embedded in the user-centred design framework. Therefore, there is the risk that user involvement in practice becomes arbitrary concerning when to ask, whom to ask, what to ask and how to ask. As a result, HF/E input is shrugged off as “feel good” measures because of the impression it only passes on users’ unfounded wishes concerning workplace design. Actually, user opinions should only be a starting point and need to be substantiated. Some methods already address rather objective measures like the operators workload or situational awareness. In practice, however, it is difficult to transfer these findings into meaningful system requirements that can be engineered eventually. Although the methods may have explanatory power (detailing why a certain solution is good or bad), they clearly lack specific design implications. It is up to the scientific community to provide adequate methods that steer user integration within a user-centred design and are able to affect the engineering process effectively.
- 3. Air Traffic Control happens in a complex environment. HF/E should acknowledge this complexity by following a systems approach.
However, it remains unclear for practitioners how exactly a systems approach will be applied, which premises it follows and how it can be incorporated into design. Specifically, more research and methods are needed that enable organisations to actively manage complexity and interdependencies.
- 4.The objective of HF/E is to optimize overall system performance and human well-being.
While it is relatively easy to demonstrate a rise in performance, human well-being remains difficult to operationalize. It becomes even more difficult, if the interest of HF/E goes beyond the prevention of physical harm and occupational healthcare. Newer approaches, that put the overall human-experience in the centre, seem more appealing with respect to design. More research is needed on how technology affects meaningful work or, even more interesting, how meaningful work can be shaped by design. HF/E should be committed to both objectives: Human well-being and overall system performance. For this, a better-suited concept for human well-being is urgently needed, which is able to compete with system performance as the dominant objective.
- 5. Resilience Engineering and Safety II are becoming more and more popular.
They are especially attractive for system design, as they recognize safety as something that can be actively shaped. Human adaptability are seen as a main resource of safe systems. More effort needs to be spent on the question, how adaptability can be incorporated in the development of new systems. While the theoretical frameworks deliver the necessary foundation, more work is needed to transfer these ideas into practice.
- 6. Another problem of HF/E seems to be the multitude of rival schools of thought, such as: cognitive systems engineering, ecological interface design, computer-human interaction, computer supported cooperative work and many more that descend from different source disciplines, such as psychology, engineering, computer science or economics.
On taking a step back, they are all concerned with the same thing, namely understanding and designing socio-technical systems, albeit with different key interests. Still, the wheel is being reinvented over and over again, as the disciplines do not necessarily interact. A separation starts during the education of HF/E experts, already. Although it depends on the academic traditions of the country of origin, HF/E courses, for example, originate mostly in psychology. This leads to an overrepresentation of cognitive aspects combined with a worldview focused on analysing and explaining. Actually applying what has been learned to produce something, be it a more abstract work process or a concrete interface, rarely happens. As regards interfaces, UX designers fill the gap. They are very good at aesthetics but lack a scientific foundation. This may work for the web, but fails for complex environments like ATM. A simple way forward would be to detach education from its historic origins (e.g. psychology and HF/E) and fuse the relevant areas of psychology, engineering, and industrial design to create a new interdisciplinary curriculum.