Summary

Evaluate as early as possible with the help of prototypes.

Principle 5: Prototyping Icon: EUROCONTROL © (All rights reserved)

Design projects start with limitless possibilities but little knowledge about the context of use. When finished, the context of use is very well known, but changes come at high-cost.

Evaluate as early as possible with the help of prototypes, which range from pen & paper to beta versions to overcome this dilemma.

One key feature of iterative user-centred design is that each cycle yields a product: the design solution. Experts and users alike can evaluate the product to determine whether and to what degree the requirements are fulfilled. Under realistic circumstances, this is never the case during the first iteration. However, it also should not be the goal. Instead, the iterative approach should be fully embraced. That means features and functionality should be introduced gradually during multiple cycles. This way, complexity can be increased in a controlled fashion. Any mistake can be fixed before it becomes too entangled with other aspects of the product. Dead ends can also be identified early and the development can take another direction without severe loss of time and budget.

We call these early and intermediate design solutions prototypes. They are somewhat different from a prototype in a typical industrial setting. There, prototypes are almost ready for production and thus almost the final “thing”. They are expensive to produce and thus hard to change or even reject. As such, they produce lock-in effects. The project is bound to specific decisions. Even though ATM systems are mostly software, the same thing happens in ANSPs. After the requirements phase, a demonstrator or alpha version is programmed. Most often, this takes so long that there is no room for substantial changes even when they are necessary. This leads to workarounds and training issues.

Different Prototypes for Different Levels of Complexity

Different Prototypes for Different Levels of Complexity Icon: EUROCONTROL © (All rights reserved)

For our purpose, prototypes can take many forms and evolve together with the design solution they represent.

In the beginning, they might represent initial concepts without much need for form or finesse. Here, it is easiest to use pen & paper methods. Such prototypes are easy to produce and modify (even during user workshops) and are cheap and disposable. Since it is easy to modify this kind of prototype, as many use cases as possible should be considered and tested. It can also be worthwhile to develop multiple different solutions and compare them at this stage. The most viable variants should then be transferred into a digital format for easier reference.

Once there is enough trust in the viability of the overall concept, the specifics have to be fleshed out. When developing a user interface, this would be the time to start using a dedicated rapid prototyping tool. This allows for a more realistic representation and some interactivity while retaining flexibility for rapid changes. Accordingly, cycles can be kept short and there is still enough room to explore different options. However, one should keep in mind that the conditions under which this kind of prototype is evaluated remain idealised and controlled. It might not run on the same hardware at the real workplace (which might not exist yet). This means not all possible side effects and influences can be seen during tests. At best, the influences are known from the context-of-use analysis and their impact can be estimated.

Icon: EUROCONTROL © (All rights reserved)

Depending on the prototyping software and how the final interface is to be implemented, it might be necessary to switch the prototyping environment to something that offers more interaction opportunities or can mimic some limited backend operation. This can be useful to evaluate more sophisticated workflows that involve more operations or coordination between different people.

The resulting final prototype should represent the design and behaviour of the product. This is why it can actually be used in addition to, or even to replace, written specifications. The software engineers can refer to the prototype to develop a better understanding for the product.

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