# Human Factors Engineering as the Methodological Babel Fish: Translating User Needs into Software Design

Neville A. Stanton

► To cite this version:

Neville A. Stanton. Human Factors Engineering as the Methodological Babel Fish: Translating User Needs into Software Design. 4th International Conference on Human-Centered Software Engineering (HCSE), Oct 2012, Toulouse, France. pp.1-17, 10.1007/978-3-642-34347-6_1. hal-01556825

HAL Id: hal-01556825

https://inria.hal.science/hal-01556825

Submitted on 5 Jul 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Human Factors Engineering as the Methodological Babel Fish: translating user needs into software design

Neville A Stanton

Faculty of Engineering and the Environment
University of Southampton
Highfield, Southampton, SO17 1BJ, UK.
Email: n.stanton@soton.ac.uk

**Abstract.** The aim of this paper is to show, by way of two case studies, the value of including Human Factors in interaction and interface design specification. It is argued that Human Factors offers and unique and useful perspective and contributes positively to design. Human Factors sits between subject matter experts and software engineers, translating user requirements though the applications of theory, models and methods. This results in software design requirements that have been intelligently interpreted and presented in a graphical manner. The two case studies demonstrate the differences between the interfaces with and without Human Factors input. Both cases show quantitative and qualitative benefits of including Human Factors in design. Performance improvements between 20-70 percent were demonstrated, which is typical of Human Factors design interventions.

**Keywords:** Human Factors Methods, Requirements Specification, Case Study.

## 1 Introduction to Human Factors Methods

The purpose of this paper is to show the benefit of Human Factors (HF) methods in system specification and design. Human Factors has a broad remit, covering all manner of analysis from human interaction with devices, to design of tools and machines, to team working, and general aspects of work and organisational design. The Human-Centred Design of Systems is also covered by the International Standard ISO13407. This emphasises the need to focus on the potential users of systems at all stages in the design and development process in order to ensure that requirements have been adequately defined and that functions are allocated between user and technology appropriately [23]. Much has been made about the timeliness of Human Factors input into projects, arguing that the appropriateness of the analysis will depend upon a number of factors [21][23][24], including which stage of design the project is at, how much time and resources are available, the skills of the analyst, access to the end-user population, and what kind of data are required [25]. Stanton and Young (1999) [25] showed that many of the methods they reviewed were flexible with regard to the design stage they could be applied to. Indeed many of the methods could be applied to very early stages of design, such as to concept models and mock-
ups. Many methods may be used in a predictive as well as an evaluative manner. This flexibility of application to the various design stages bodes well for Human Factors methods. Other factors that the analyst needs to be aware of when choosing methods are: the accuracy of the methods (particularly where a predictive element is involved), the criteria to be evaluated (such as time, errors, communications, movement, usability, and so on), the acceptability and appropriateness of the methods (to the people being analysed, the domain context, resources available, and so on), and the cost-benefit of the method(s) and the product(s). Methods form a major part of the Human Factors discipline. For example, the International Encyclopaedia of Human Factors and Ergonomics [13] has an entire section devoted to methods and techniques. Many of the other sections of the encyclopaedia also reference to, if not provide actual examples of, Human Factors methods. In short, the importance of Human Factors methods cannot be overstated. These methods offer the ergonomist a structured approach to the analysis and evaluation of design problems. The Human Factors approach may be described using the scientist-practitioner model [23]. As a scientist, the Human Factors researcher is:

* extending the work of others;

* testing theories of human-machine performance;

* developing hypotheses;

* questioning everything;

* using rigorous data collection and analysis techniques;

* ensuring repeatability of results;

* disseminating the finding of studies.

As a practitioner, the Human Factors engineer is:

* addressing real-world problems;

* seeking the best compromise under difficult circumstances;

* looking to offer the most cost-effective solution;

* developing demonstrators and prototype solutions;

* analysing and evaluating the effects of change;

* developing benchmarks for best practice;

* communicating findings to interested parties.

According to Stanton et al (2005) [23] Human Factors will work somewhere between the poles of scientist and practitioner, varying the emphasis of their approach depending upon the problems that they face. Human Factors and Ergonomics methods are useful in the scientist-practitioner model, because of the structure, and potential for repeatability, that they offer. There is an implicit guarantee in the use of methods that, provided they are used properly, they will produce certain types of useful products. It has been suggested that Human Factors and Ergonomics methods are a route to making the discipline accessible to all [10][26]. Despite the rigor
offered by methods however, there is still plenty of scope for the role of experience. Annett and Stanton (2000) [3] summarised the most frequently asked questions raised by users of Human Factors methods as follows:

* How deep should the analysis be?

* Which methods of data collection should be used?

* How should the analysis be presented?

* Where is the use of the method appropriate?

* How much time/effort does each method require?

* How much, and what type, of expertise is needed to use the method(s)?

* What tools are there to support the use of the method(s)?

* How reliable and valid is/are the method(s)?

Annett (2002) [1] questions the relative merits for construct and criterion-referenced validity in the development of Human Factors theory. He distinguishes between construct validity (how acceptable the underlying theory is), predictive validity (the usefulness and efficiency of the approach in predicting the behaviour of an existing or future system), and reliability (the repeatability of the results). Investigating the matter further, Annett identifies a dichotomy of Human Factors methods: analytical methods and evaluative methods. Annett argues that analytical methods (i.e., those methods that help the analyst gain an understanding of the mechanisms underlying the interaction between human and machines) require construct validity, whereas evaluative methods (i.e., those methods that estimate parameters of selected interactions between human and machines) require predictive validity. This distinction is made in **Table 1**.

<table><caption>**Table 1.** Annett's dichotomy of Human Factors methods (adapted from Annett, 2002 [1]).</caption><thead><tr><td></td><td>Analytic</td><td>Evaluative</td></tr></thead><tbody><tr><td>Primary purpose</td><td>Understand a system</td><td>Measure a parameter</td></tr><tr><td>Examples</td><td>Task analysis, training needs analysis, etc.</td><td>Measures of workload, usability, comfort, fatigue, etc.</td></tr><tr><td>Construct validity</td><td>Based on an acceptable model of the system and how it performs</td><td>Is consistent with theory and other measures of parameter</td></tr><tr><td>Predictive validity</td><td>Provides answers to questions, e.g., structure of tasks</td><td>Predicts performance</td></tr><tr><td>Reliability</td><td>Data collection conforms to an underlying model</td><td>Results from independent samples agree</td></tr></tbody></table>

This presents an interesting question for Human Factors, are the methods really mutually exclusive? Some methods appear to have dual roles (i.e., both analytical and evaluative, such as Task Analysis For Error Identification), which implies that they must satisfy both criteria. However, it is plausible, as Baber (2005) [4] argues in terms of evaluation, that the approach taken will influence which of the purposes one
might wish to emphasise. The implication is that the way in which one approaches a
problem, e.g., along the scientist-practitioner continuum, could well have a bearing on
how one employs a method. At first glance (particularly from a 'scientist'
perspective) such a 'pragmatic' approach appears highly dubious: if we are selecting
methods piecemeal in order to satisfy contextual requirements, how can be certain
that we are producing useful, valid, reliable etc. output? While it may be possible for
a method to satisfy three types of validity: construct (i.e., theoretical validity), content
(i.e., face validity), and predictive (i.e., criterion-referenced empirical validity), it is
not always clear whether this arises from the method itself or from the manner in
which it is applied. This means that care needs to be taken before embarking on any
application of methods to make sure that one is attempting to use the method in the
spirit for which it was originally designed.

Prior to embarking on any kind of intervention (be it an analysis, design or
evaluation of a system), an Ergonomist needs to have a strategy for deciding what
methods to use in and how to adapt to the domain context [2]. Determining an
appropriate set of methods (because individual methods are rarely used alone),
requires some planning and preparation. Stanton and Young (1999) [25] proposed a
process model to guide the selection of methods, as shown in Fig. 1. As Annett
(2005) [2] points out, care and skill is required in developing the approach for
analysing the problem, formulating the intervention, implementing the intervention,
and determining the success of the intervention. Complex systems may require the
Ergonomist to have a flexible strategy when approaching the problem. This can mean
changing the nature of the analysis and developing a new approach as required. Thus,
pilot studies are often helpful in scoping out the problem, before a detailed study is
undertaken. This may mean that there can be several iterations through the criteria
development and methods selection process. Of course, from a practitioner
perspective, the time taken to carry out pilot studies might simply be unavailable.
However, we would argue that there is no harm in running through one's selection of
methods as a form of 'thought-experiment' in order to ascertain what type of output
each method is likely to produce, and deciding whether or not to include a method in
the battery that will be applied. While it is important not to rely too heavily on a
single approach, nor is there any guarantee that simply throwing a lot of methods at a
problem will guarantee useful results.
<figure><img src="image_2.png" /><figcaption>**Fig. 1.** Validating the methods selection and Human Factors intervention process (adapted from Stanton & Young, 1999 [25]).</figcaption></figure>

As shown in **Fig. 1**, method selection is a closed loop process with three feedback loops. The first feedback loop validates the selection of the methods against the selection criteria. The second feedback loop validates the methods against the adequacy of the ergonomic intervention. The third feedback loop validates the initial criteria against the adequacy of the intervention. There could be errors in the development of the initial criteria, the selection of the methods, and the appropriateness of the intervention. Each should be checked. The main stages in the process are identified as: determine criteria (where the criteria for assessment are identified), compare methods against criteria (where the pool of methods are compared for their suitability), application of methods (where the methods are applied)), implementation of Human Factors intervention (where an Human Factors programme is chosen and applied) and evaluation of the effectiveness of the intervention (where the assessment of change brought about by the intervention is assessed).

Two case studies are presented to demonstrate the added-value of Human Factors to system design and engineering. They also demonstrate some aspects of the requirements specification process. The first case study is based on the development of the drivers interface for a Stop and Go Adaptive Cruise Control system. Further information on the system development and evaluation may be found in Stanton et al (2011) [20]. The second case study is based on the development of the pilots interface for a Mission Communication Planning system. Further information on the system development and evaluation may be found in Stanton and McIlroy (2012) [2221].
## 2 Case Study 1: Stop & Go Adaptive Cruise Control

Stop & Go Adaptive Cruise Control (S&G-ACC) is a system that maintains cruise speed in the same way as a conventional cruise control system, but also maintains the gap to the vehicle ahead by operating the throttle and brake systems. The S&G-ACC control module is mounted at the front of the vehicle, which uses radar to measure the gap and closing speed to the vehicle ahead. Once the vehicle has become stationary, the driver must intervene. This can be achieved by pressing the resume button, which will reactivate S&G-ACC providing a sufficient distance to the vehicle ahead has been attained, or by depressing the throttle, which will always override the system. The system is immediately cancelled by either the cancel button or driver braking. S&G-ACC is an extension to regular ACC, which has previously only operated above 26 kph. The capability of S&G-ACC over ACC is achieved by adding radar that can operate at slow speeds over short distances. The system has a built-in monitoring capability and so the speed is limited to that chosen by the driver, and the level of deceleration is also limited by the designers of the system. The system will not undertake emergency braking and under such conditions the driver will be required to intervene. When the driver is required to operate the brakes, i.e. the maximum S&G ACC brake level is reached, the system warns the driver by an audible warning. Due to the limited braking of the system, the driver may be called upon to intervene when approaching a slow moving or stationary object. The likelihood of the driver needing to intervene increases with the speed of the vehicle. The S&G-ACC system had also been designed for assistance in queuing scenarios, to keep a set distance behind slow moving vehicles.

The original system to be tested presented an amber follow icon when the vehicle enters follow mode and the icon is extinguished when the vehicle leaves follow mode. This is the simplest interface, as shown in Fig. 2a. A re-development of this interface was to indicate the presence of a new in-path target (e.g., a new vehicle) by flashing the icon red at first (as shown in Fig. 2b), before assuming steady state of the amber icon. The third interface represented a departure from the follow icon design. This interface encapsulated the driver requirements on temporal, spatial and mode information, by mapping the in-path target data onto a representation of the radar display (as shown in Fig. 2c). This offered a direct relationship between the position of the in-path target in the world (i.e., the position of another road user) and its representation on the driver interface (i.e., the highlighted ball in the centre of the display at 21 metres).
<figure><img src="image_3.png" /><figcaption>Fig. 2. The standard icon display.</figcaption></figure>

<figure><img src="image_4.png" /><figcaption>**Fig.2b.** The flashing red icon (left) followed by the standard icon (right) display.</figcaption></figure>

<figure><img src="image_5.png" /><figcaption>**Fig.2c.** The radar display analogy.</figcaption></figure>

The mapping between the different interface designs and the elements of Situation Awareness (SA) is indicated in **Table 1**. As **Table 2** shows, all three interface designs support mode awareness but only the radar display supports spatial awareness and, to a limited extent, temporal awareness. Cognitive mismatch is a general problem for automated systems [5], so design needs to focus on communication of the appropriate modal, spatial and temporal information. It was therefore anticipated that performance of drivers, in detecting new in-path targets that had been acquired by the S&G-ACC system, would be superior with the radar display. Seppelt & Less (2007) [19] argue that interface design needs to communicate the system limits in a continuous manner to the driver. The radar display analogy offers continuous information on modal, spatial and temporal changes (which the driver can compare to
information in the world) whereas the two other iconic displays only communicate discrete information on modal changes.

<table><caption>**Table 2.** Mapping interface design and the SA elements.</caption><thead><tr><th>Interface Design</th><th>Modal Awareness</th><th>Temporal Awareness</th><th>Spatial Awareness</th></tr></thead><tbody><tr><td>Standard Icon</td><td></td><td></td><td></td></tr><tr><td>Flashing Icon</td><td></td><td></td><td></td></tr><tr><td>Radar Display</td><td></td><td></td><td></td></tr></tbody></table>

The dark shaded area in **Table 2** indicates that the interface supports the type of SA. For example the standard and flashing icons only support mode awareness, because they are only lit if a target vehicle is being tracked by the S&G-ACC system, which changes the vehicle from 'cruising' mode to 'following' mode. As well as mode awareness, the radar display can also communicate spatial awareness information, i.e., the range and direction of the target vehicle. Some limited temporal awareness information may also be communicated via the radar display (shown by the lighter shading) as the target gets closer to or further on away from the host vehicle, i.e., the rate of approach of the target vehicle. Additional time-to-contact information would need to be provided to better support time situation awareness. For the driver of a car with S&G-ACC, spatial relevance of other vehicles (e.g., longitudinal and lateral position of in-path target), temporal relevance of other vehicles (e.g., time to impending contact), and modal relevance of other vehicles (e.g., acquisition of a new in-path target or not) are extremely important. Integration of all this information should help to ensure that the driver responds appropriately to the dynamic road-vehicle environment. Bookhuis et al (2008) [7] report high driver acceptance of a congestion assistant that was functionally similar to the S&G-ACC system. Further Bliss and Acton (2003) [6] propose that drivers are more likely to accept systems that have greater operational reliability in reporting of information about the state of the world as well as optimizing driver responses.

As shown in **Fig. 3**, far fewer changes in in-path target were detected with the icon interfaces. This suggests that driver's were more likely to commit mode errors in these conditions, as they were less able to detect the fact that the S&G-ACC system had acquired a new in-path target and was no longer tracking the old one. With multiple in-path targets present, it would seem to be important that the driver should know which one is being tracked by the S&G-ACC system. In summary, drivers were more able to detect the change of an in-path target with the radar display than the two icon displays (based on data from in-path, multiple-target, test - to simulate a vehicle queuing scenario where other road users (such as cyclists, pedestrians and motorcyclists) might pass between the host vehicle and the tracked vehicle). This means that, in a situation with multiple vehicles, drivers were more likely to mistake the target vehicle being tracked by the automatic S&G-ACC system when using the iconic interfaces.
<figure><img src="image_6.png" /><figcaption>Fig. 3. Detection rates by drivers using the three interfaces.</figcaption></figure>

The finding that drivers in the iconic display conditions were less able to identify
changes of the in-path targeting by the system, raises the idea that mode errors were
more prevalent in iconic conditions, as the drivers’ reports of system status departed
from its actual status. Mode errors are of particular interest, because they are the
result of people’s interaction with technology. In his classification of human errors,
Norman (1981) [16] singled this error type out as requiring special attention in the
design of technological systems. The misclassification of the mode of the automatic
S&G-ACC system could lead to driver errors which might have serious effect. Mode
awareness by the driver should be of utmost importance. A measure of the success of
the design will be the extent to which drivers are aware which mode the system is in,
and how that relates to the behaviour of the vehicle in any given situation. The mode
errors in this study were related to the drivers’ failure to appreciate that the automatic
system had changed its in-path target vehicle. This means that the driver thought that
the S&G-ACC system was tracking one target whilst, in fact, it was tracking another.
Other studies have shown that mode errors can have potentially disastrous outcome
on system performance [17][18][27]. In the case of S+G-ACC, one can imagine a
scenario where the host vehicle is tracking a leading vehicle when a motorcycle pulls
between the host and tracked vehicle. The question for the driver of the host vehicle
is whether the S&G-ACC system had acquired the motorcycle as the new in-path
target, or is still tracking the original vehicle. This judgment becomes even more
important if the original tracked vehicle increases its speed, as the host vehicle will
similarly increase speed in order to maintain the gap between the two vehicles [19].
If the driver is able to determine that the S&G-ACC has not acquired the motorcycle as the new in-path target, then they will be able to prepare for a manual intervention. The findings from the study reported in this paper suggest that the radar display will be more useful to the driver in the scenario described above than the iconic displays in reducing cognitive mismatch [5] and these effects are likely to become more marked over time [14].

## 3 Case Study 2: Mission Communications Planning

The main function of the MPS communications software is to allow helicopter pilots to load a collection of radio frequencies such that when airborne, pilots have easy access to all of the frequencies they will require, and that each of these frequencies is properly labelled with regards to where and with whom that frequency is associated. The MPS software contains a visual display of a map of the United Kingdom displaying the boundaries of all major controlled airspaces, including military danger zones and minor and major air fields and airports. By studying the proposed route, marked on the map by a solid black line, pilots must decide what frequencies they will need for their mission. These frequencies must then be looked up in one of the Royal Air Force (RAF) Flight Information Publications, for example the British Isle and North Atlantic en-route supplement (BINA). A detailed description of the process of planning communications in MPS can be found in McIlroy, Stanton and Remington (2012) [15] and in Stanton and McIlroy (2012) [22].

In its present guise, the communication planning software interface is perceived as difficult to use, which has implications for training and mission planning, as indicated by the following quotes from experienced pilots who also train others:

> "The AH has an incredibly capable communications suite. However, it is regularly under-utilised by the front-line as the planning and setup process is overly complicated and error prone."

> "Training aircrew to configure the wide variety of voice, data and frequency agile encrypted radios on the Helicopter is an overly intensive task for both staff and students - primarily due to the overly complex tools used to configure various radio, channels & Nets."

Some of the complexity is due to the inherent complexity of the system components (e.g., there are 4 radios, 60 call-signs, 10 presets, 4 boot-up channels – all doubled for a two day communications plan) coupled with the constraints acting on communications planning (e.g., the standard operating procedures for communications settings, the mission timings, changes in airspace authority and so on). Helander (2007) [11] notes that computerisation of systems is making the coupling of systems even more complex, and that uncoupling of system elements may make interaction design more achievable. Although the current generation of communications planning starts with the presentation of a map with a route, communications planning resorts to a series of tables, fields and buttons (as shown in
**Fig. 4).** We suspect that this results in a disconnection between how pilots think about planning their communications and what the software requires of them to prepare a communications plan. This line of reasoning was explored in the research presented within the current paper.

<figure><img src="image_7.png" /><figcaption>**Fig. 4.** The call-sign frequency list for the communications planning.</figcaption></figure>

At the beginning of the project, two full day meetings were held with a subject matter expert (SME) in which the analysts were introduced to military communications in general and to the current software technology in particular. The analysts were supplied with a version of the MPS software to inform analyses. Across a further six days, the analysts worked with the SME to further their understanding of the mission planning process and the MPS software through SME walkthroughs of different communications planning tasks. During these meetings the SME produced a number of Rich Pictures [8] of the communications planning task. A Rich Picture is graphical representation of a problem, concept, situation or work domain. It can include any kind of figure or text and has no prescribed rules or constraints. The Rich Picture has its origins in Soft Systems Methodology [8][9] and its primary purpose is to describe a system in such a way that is useful to both individuals external to, and actors within that system; it serves to organise and structure the body of information
provided by the expert. Rich Pictures are commonly used in information systems education [12], as they can often provide easily interpretable depictions of complex systems. An example of the Rich Picture for the concept of air-to-ground communications is presented in **Fig. 5**. In the route is displayed by the solid line with waypoints and circles on the line. The dashed circles indicate airspace boundaries associated with an airfield (the cross on a circle in the centre of the airspaces). The dashed line indicates the planned diversion. The boxes represent collections of frequencies associated with each airfield.

<figure><img src="image_8.png" /><figcaption>**Fig. 5.** Rich Picture of air-to-ground communications.</figcaption></figure>

One of the most significant problems with MPS was the lack of correspondence between the user's mental model and the system model. A mental model is an internal, mental representation of the way things exist or work in the real world. A mismatch between system model and user mental model results in a system that is unintuitive; the way the user thinks about the task is not reflected in the way the user must interact with the system. Rather than relying on a mental representation of the task to guide behaviour the user must use a learnt sequence of actions to progress through the system. For the air-to-ground communications planning stage of the task, results from a think-aloud study (reported in McIlroy, Stanton, & Remington, 2012 [15]) suggested that thought processes are map based. The expert explicitly stated that he was using the map to not only guide the decision making process (when deciding which frequencies to include in the plan) but also when getting an overview of the plan so far and when reviewing the completed plan. The Rich Picture presented earlier underlines this mismatch. In this diagram the SME graphically represented his
concept of the air-to-ground communications process. The route is presented in such a
way as to draw attention to those airspaces that are passed through, and those that are
close by. Furthermore frequencies are directly linked to an airspace (indicated by the
boxes in Fig. 5); they are not in a separate table only identified by ICAO
(International Civil Aviation Organisation) codes (as is the case with the current
version on the system and the frequencies are in a separate window shown in Fig. 4,
which covers the map).

Another significant issue pertaining to the volume of information requiring
management was relatively straightforward to address. In the current system the user
must refer to a reference document (BINA) in order to get the frequencies associated
with each airspace controlling authority. They must refer to a different reference
document (RAF flight information handbook) to find out the name of an airport,
airfield or special user airspace from the ICAO code given in the CSF or preset
channels list, as these names are not contained within MPS. All of this information,
although currently used from a paper-based format, is also held within an electronic
database, the Digital Aeronautical Flight Information File (DAFIF). The information
held in this file covers the entire globe, and all authorities contained within the file
have both frequencies and coordinates associated with them. By taking advantage of
this information it is possible to directly link frequency data with map data. In
addition, the name of each airspace controlling authority can be displayed with the
ICAO code. By linking communications data to the map, the problems of both task
organisation and mental model mismatch are addressed, at least for air-to-ground
communications.

**Fig. 6** displays a screenshot of the proposed interface; on it, a map with a route
marked on it is displayed as it would be in MPS, with the exception that there are
communication symbols and frequency tables included. The symbols indicate that
there is some communications information associated with that position on the map
whilst the tables display that information. The symbols were designed and refined in
an iterative process via repeated meetings with a subject matter expert. The symbol is
displayed on a white background on the so that even if the map is predominately a
dark colour, the symbols will still be clear to the user. The symbols are displayed just
off centre of the airspace such that runway information is not obscured. The distance
of the icon from the centre of the airspace is based on distance on the screen, not map-
based geographical distance.
<figure><img src="image_9.png" /><figcaption>**Fig. 6.** Example new communications planning interface.</figcaption></figure>

For each airspace a label displaying all associated frequencies is presented alongside a number of options for selection. This presentation of frequencies is largely based on the depiction of frequencies in the Rich Picture for air-to-ground communications, in Fig. 5. To compare the proposed system with the current MPS software tool two simulations were created; a simple one comprising 4 contactable airspace authorities and a complex one containing 8 contactable airspace authorities. The simulations, based on a series of possible screenshots, were constructed such that the amount of mouse travel, number of mouse clicks and number of keystrokes necessary to complete the plan could be recorded (see Table 3). Although the sequence of actions was fixed for each simulation, the method for advancing through the simulated plans was a realistic one. By moving the mouse cursor to the relevant area on the screen and only then clicking to progress it was possible to estimate the amount of mouse travel and number of mouse clicks necessary to complete the plan. The number of keystrokes was estimated from the amount of information requiring insertion by typing.
<table><caption>**Table 3.** Results for simple and more complex communications plan.</caption><thead><tr><th rowspan="2"></th><th colspan="3">Findings for simple plan</th><th colspan="3">Findings for more complex plan</th></tr><tr><th>Current system</th><th>Proposed system</th><th>Percent decrease</th><th>Current system</th><th>Proposed system</th><th>Percent decrease</th></tr></thead><tbody><tr><th>Mouse travel (m)</th><td>19</td><td>9</td><td>52</td><td>26</td><td>22</td><td>17</td></tr><tr><th>Mouse clicks</th><td>206</td><td>86</td><td>58</td><td>283</td><td>120</td><td>58</td></tr><tr><th>Keystrokes</th><td>291</td><td>32</td><td>89</td><td>534</td><td>116</td><td>78</td></tr><tr><th>Time (mins)</th><td>22</td><td>5</td><td>77</td><td>32</td><td>10</td><td>69</td></tr></tbody></table>

To verify the validity of the proposed system a focus group with a number of SMEs was arranged. During the focus group, which lasted for approximately 6 hours, four Helicopter pilots (responsible for training new recruits in MPS) and two software engineers were present along with the researchers. A presentation was given in which the research conducted, and the resulting proposed system were explained at length. Comments, suggestions and criticisms were encouraged, and although a number of minor changes and additions were recommended, the proposed system was accepted as a vast improvement on the MPS software tool. All of the recommendations to come from the focus group were implemented, and all are contained within the proposed system.

## 4 Conclusions

In the first case study of Stop and Go Adaptive Cruise Control, the relative merits of different approaches to in-car display design, several conclusions may be drawn from the work presented in this paper to do with design of the driver interface and testing of that interface on drivers. The interface need only capture the essential features to enable the driver to make direct mappings between the world and the representation of it. In terms of the dynamics of S&G-ACC, this would include the representation of the leading vehicle, its spatial reference to the host vehicle (i.e., spatial situation awareness), an indication of whether or not the leading vehicle has changed (i.e., modal situation awareness), and leading headway of the in-path target vehicle (i.e., temporal situation awareness). Spatial representation is perhaps the easiest to design, and the radar display design attempted to show the relation between the in-path target vehicle and the host vehicle. Modal awareness is more difficult, as it requires representation of a change in state of the system. The flashing of the ‘ball’ in the radar display (and flashing icon in the icon display) is one way of drawing the driver’s attention to the fact that a new target has been detected. Whatever representation is chosen, it needs to be able to communicate the information quickly and effectively to the driver [5][19]. Temporal awareness is even more difficult to display. None of the interfaces in the study communicated this information completely effectively. A digital time-to-contact displaying ‘seconds’ could communicate this information, but it would increase workload dramatically.

In the second case study, the Rich Pictures [8][9] were constructed by an SME primarily to the researchers gain a fuller understanding of the communications
planning task independent of MPS. Not only did the pictures gave a valuable insight
into the way in which the expert conceives the task, they also proved an invaluable
tool in designing the interface for the proposed communications planning system. The
air-to-ground Rich Picture was particularly useful in inspiring the design of the new
system; it outlined the SME's representation of the task, showing that the arrangement
of frequencies is not list-based but organised into groups of frequencies, each relating
to an airspace controlling authority on the map of the ground. The representation of
the aircraft's route as it travels through and around airspaces was similar to
representation of the route on the map display in MPS; the major difference being that
the selection of frequencies, i.e. who will need to be contacted, is done while studying
the route, not after studying the route. This has been capitalised on in the proposed
system; frequencies are directly tied to the map and can be selected from that view.
Mapping the structure of the system interface and interaction design to the user's
conceptual models of communications planning has increased the usability of the
mission planning software for the communications planning task.

In conclusion, the aim of this paper has been to demonstrate the valuable
contribution the Human Factors has to make in the specification and design of
systems. The unique insights that arise from the application of Human Factors
theories, models and methods appear to result in a deeper understanding of the
interactions between people, the tasks they are performing and the requirements for
interactions and technological interfaces. Human Factors approaches are both
system-oriented (i.e., focusing on the interactions) and systematic (i.e., structured and
holistic). The value they add, over and above traditional software engineering, seems
self-evident in the two case studies presented. Both projects were undertaken with
engineers and subject matter experts who had been involved in the previous design
solutions. The role that Human Factors played in these projects was to translate the
user requirements into meaningful design representations (i.e., graphical rather than
textual) that the engineers could readily code into a prototype interface. It is apparent
that this did not occur to the same extent in previous iterations of the interfaces. The
benefits were demonstrated in the evaluation, which show improvements of between
20-70 percent over the more traditional design approaches. These benefits are typical
of Human Factors interventions.

References

1. Annett, J. (2002) A note on the validity and reliability of ergonomics methods. Theoretical Issues in Ergonomics Science, 3 (2), 229-232.

2. Annett, J. (2005) Conclusions. In: J. R. Wilson and E. N. Corlett (eds) Evaluation of Human Work. 3rd Edition. Boca Raton, Fl: CRC Press, 1009-1013

3. Annett, J., Stanton, N. A. (2000) Task Analysis. London: Taylor and Francis.

4. Baber, C. (2005) Evaluating Human-Computer Interaction, In: J.R. Wilson and E.N. Corlett (eds) Evaluation of Human Work, 3rd Edition. Boca Raton, Fl: CRC Press, 357-388.

5. Baxter, G., Besnard, D., Riley, D. (2007) Cognitive mismatches in the cockpit: Will they ever be a thing of the past? Applied Ergonomics, 38, 417-423.

6. Bliss, J. P., Acton, S. A. (2003) Alarm mistrust in automobiles: how collision alarm reliability affects driving. Applied Ergonomics, 34, 499-509.
7. Brookhuis, K.A., van Driel, C.J.G., Hof, T., van Arem, B., Hoedemaeker, M., (2008) Driving with a congestion assistant: mental workload and acceptance. Applied Ergonomics 40, 1019-1025.

8. Checkland, P. (1981) Systems Thinking, Systems Practice. Chichester: John Wiley & Sons.

9. Checkland, P., Scholes, J. (1990). Soft systems methodology in action. Chichester, England: John Wiley & Sons.

10. Diaper, D. (1989) Task Analysis in Human Computer Interaction. Chichester: Ellis Horwood.

11. Helender, M. G. (2007) Using design equations to identify sources of complexity in human-machine interaction Theoretical Issues in Ergonomics Science, 8 (2) 123-146.

12. Horan, P. (2002) A new and flexible graphic organiser for IS learning: The Rich Picture. Proceedings of Informing Science conference & IT Education Conference, Cork, Ireland, (pp. 133-138). Informing Science Institute.

13. Karwowski, W. (2001) International Encyclopaedia of Ergonomics and Human Factors Vols I-III. Taylor & Francis, London.

14. Lai, F., Hjalmdahl, M., Chorlton, K., Wiklund, M. (2010) The long-term effect of intelligent speed adaptation on driver behaviour. Applied Ergonomics, 41, 179-186.

15. McIlroy, R.C., Stanton, N.A., Remington, B. (2012), Developing expertise in military communications planning: Do verbal reports change with experience? Behaviour and Information Technology. 31 (6), 617-629.

16. Norman, D. A. (1981) Categorisation of action slips. Psychological Review, 88, 1-15.

17. Norman, D. A. (1990) The "problem" with automation: Inappropriate feedback and interaction, not "overautomation". Philosophical Transaction of the Royal Society of London, B, 327, 585-593.

18. Reason, J. (1990) Human error. Cambridge: Cambridge University Press.

19. Seppelt, B. D., Lee, J. D. (2007) Making adaptive cruise control (ACC) limits visible. International Journal of Human Computer Studies, 65, 192-205.

20. Stanton, N. A., Dunoyer, A., Leatherland, A. (2011) Detection of new in-path targets by drivers using Stop & Go Adaptive Cruise Control, Applied Ergonomics, 42 (4), 592-601.

21. Stanton, N. A., Hedge, A., Salas, E., Hendrick, H., Brookhaus, K. (2005) Handbook of Human Factors and Ergonomics Methods. Taylor & Francis: London.

22. Stanton, N. A., McIlroy, R. C. (2012) Designing mission communication planning: the role of Rich Pictures and Cognitive Work Analysis, Theoretical Issues in Ergonomics Science, 13 (2), 146-168.

23. Stanton N.A., Salmon P.M., Walker G.H., Baber C., Jenkins D., (2005). Human Factors Methods: A Practical Guide for Engineering and Design (1st edition). Ashgate Publishing Ltd, Aldershot, UK

24. Stanton N.A., Salmon P.M., Walker G.H., Baber C., Jenkins D., (2013). Human Factors Methods: A Practical Guide for Engineering and Design (2nd edition). Ashgate Publishing Ltd, Aldershot, UK.

25. Stanton, N. A., Young, M. (1999) A Guide to Methodology in Ergonomics: Designing for Human Use. Taylor & Francis: London.

26. Wilson, J. R. (1995) A framework and context for ergonomics methodology. In: J. R. Wilson and E. N. Corlett (eds) Evaluation of Human Work. 2nd Edition. Taylor & Francis, London. (1-39).

27. Woods, D. D.; Johannesen, L. J.; Cook, R. I., Sarter, N. B. (1994) Behind Human Error: Cognitive Systems, Computers and Hindsight. Ohio: CSERIAC.