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/Principle 2: User-Centred Design Rationale
From SKYbrary Wiki
Make a coherent user-centred-design rationale your HF/E product
A clear user-centred rationale is often missing in ATM development. Today, system design mainly follows functional considerations.
Make a coherent user-centred design rationale your HF/E product that can be seamlessly integrated into early phases of the engineering process.
HF/E is design driven and therefore not limited to evaluation and analysis of existing workflows and systems, regardless of whether they are prototypical or already in operation. The question remains what HF/E can contribute to a product that does not yet exist. In the early stages of a design process, little is determined, leaving a lot of freedom to HF/E experts to incorporate their ideas and principles. But how? The lack of a clear-cut HF/E product makes a seamless integration into engineering processes difficult.
One such product could be to provide a design rationale from a user perspective. This rationale guides all concept development in early phases and can be used for all the trade-off studies and open questions during the ongoing development.
If we look at today’s ATC workplaces, a clear user-centred design rationale is often missing. Usually it is rather unclear why a controller working position and its humanmachine interface (HMI) look the way they do. The design mostly follows functional considerations, mainly from an engineering perspective: There is a certain amount of data in the system that needs to be conveyed to the user for manipulation.
Consequently, there is a need for inputs to keep the software processes going. It is not that these data and inputs are displayed completely arbitrary; they just follow other (mostly technical) paradigms, which are not necessarily user centric. The result is an HMI that theoretically provides everything that is needed but does not reflect real workflows in practice. It hampers performance and may lead to potentially unsafe situations.
Who, if not HF/E experts could and should provide such a user-centred design rationale? Typically, any HF/E activity starts with a thorough examination of the underlying goals and tasks. Without a clear understanding of the underlying tasks, needs, constraints and strategies of the users, there is no way to achieve a match between the intentions of the users and the possibilities the software offers. This is what Don Norman (1986) describes as the gulf of execution. This is also true for the opposite direction, the gulf of evaluation: How well is the system state represented and does it fit the mental model the user has of the system and its processes?
In this role, HF/E prepares, discusses and evaluates different design alternatives and interaction modes through the application of a user-centred design process. Furthermore, HF/E experts ensure the adherence to design standards and best practices in order to avoid the use of (too many) colours, small-sized fonts, low contrasts and to prevent high information densities and inconsistencies between different displays, etc.
Engineering and HF/E may perfectly complement each other. Although they come from different directions (feasibility vs. usability), they both target the HMI as the final product for the end user. Therefore, both streams should not work independently from each other. What matters is that both streams are well integrated (see Principle 1). A coherent user-centred design rationale then develops its full potential.
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