Diagnosing Co-ordination Problems in the Emergency Management Response to Disasters

Diagnosing Co-ordination Problems in the Emergency Management Response to Disasters

Becky Hill

UCL Interaction Centre, MPEB 8th Floor, University College London, Gower Street, London WC1E 6BT, United Kingdom

John Long's Comment 1 on this paper

I have known and worked with Becky Hill for more than 20 years, which is quite a long time by any standards. Following her first degree in Psychology at UCL, she completed her MSC, for which I was her Director of Studies. She went on to become a Research Fellow, then Senior Research Fellow, Project Manager and Lecturer, during my time as Director of the Ergonomics and HCI Unit. I was also the first supervisor of the PhD thesis, upon which her Festschrift contribution is based. I much appreciated her as a colleague and as a friend (and still do). It is hard to think of a more suitable and worthy contributor to the Festschrift. Her contribution well represents the ‘models and methods’ research of the Ergonomic and HCI Unit (Long, 2010).


In the United Kingdom, there is a system for the co-ordination of the emergency services in response to disasters – The Emergency Management Combined Response System (EMCRS). This is a general management framework with a complex three tier command and control system, set-up by the UK government in response to a need for better co-ordination between agencies, when they respond to disasters.

This research has developed models of the implementation of the EMCRS for specified disaster scenarios, that support diagnosis of co-ordination problems between agencies. Data for the modelling were acquired by means of training exercises. The co-ordination problems were identified through behaviour conflicts between the agencies. For example: the Fire Service behaviours of setting up a cordon around the disaster site conflict with the Ambulance Service behaviours of accessing the site for treatment of casualties. Model development was achieved through application of an existing framework.

The EMCRS models constitute substantive Human Computer Interaction design knowledge, that is, knowledge that is both explicit and supports design. One view of HCI (Long, 1996) is that of an engineering design discipline, whose research validates design knowledge, both substantive and methodological. Design knowledge supports design practice directly, as the diagnosis of design problems and indirectly, as the prescription of design solutions. An initial method for co-ordination design problem diagnosis by means of EMCRS models has been developed. This paper will describe the development of the EMCRS models and will apply the method and show the diagnosis from this application, of one co-ordination design problem.

Comment 2
The research corresponds well with Salter’s Figure 8 (2010), Design Research Exemplars. The ‘Design Problems’, diagnosed by Hill, correspond to the ‘Specific Requirements Specification’ and the ‘Design Solutions’ prescribed correspond to the ‘Specific Artefact Specification’. In the research, the former empirically verified the latter and the latter was empirically derived from the former. If, and when, the research is completed, the ‘Derivation’ and ‘Verification’ would then be formal. Design Practice Exemplars (Salter’s Figure 7) would then be enabled.

1. Introduction

The aim of this paper is to show the development of models of the Emergency Management Combined Response System that can be used to diagnose inter-agency co-ordination problems. In the United Kingdom, there exists a system for the co-ordination of the emergency services in response to disasters, such as explosions, air crashes etc. – the Emergency Management Combined Response System (EMCRS) (Anon., 1994, 2001). This system manages, that is, plans and controls, agencies, such as Fire and Police, when they respond to disasters. The EMCRS was set up to support better co-ordination between agencies responding to disaster, in reaction to a succession of enquiries into disasters e.g. Hidden (1989) and Fennell (1988), which identified problems with co-ordination, both within and between the emergency services in their disaster response. Co-ordination in this context is defined as the ‘harmonious integration of the expertise of all the agencies involved with the object of effectively and efficiently bringing the incident to a successful conclusion’ (Emergency planning college document, 1995).

Comment 3
The Emergency Management Combined Response System (EMCRS), object of Hill’s research, manages the complex domain of disasters. Like other complex domains, for example, Nuclear Power, Air Traffic, Health Services, Manufacturing etc, the industries themselves and their regulators have definitions, which conceptualise these domains. In the case of the EMCRS, the Emergency Planning Document (1995) defines ‘co-ordination’, as the ‘harmonious integration of the expertise of all the agencies involved (that is, Fire, Police and Ambulance) with the object of effectively and efficiently bringing the incident (that is, the disaster) to a successful conclusion.’ Such definitions constitute a potential problem for researchers, because they also need to conceptualise the domain for the purposes of their research, for example, for modeling or other theory purposes.

Two extreme options suggest themselves. The researchers simply adopt completely the domain definitions. Alternatively, the researchers ignore the latter and work with definitions, provided by earlier research, either their own or that of other researchers. Both options have strengths and weaknesses. The first option may find domain definitions hard or indeed impossible to operationalise. However, communicating the research results to the domain community should prove easy. The reverse is the case for the second option. Research conceptualisations are likely to be easier to operationalise. However, communicating the research results to the domain community is likely to prove more difficult.

Hill’s solution to this potential problem is interesting, because it draws from both extreme options. As concerns the definition, cited earlier, Hill appears to accept it or at least to work within it (see Section 1.0 Introduction, Paragraph 1). She develops the concept of ‘effectiveness’ in the research; but not those of ‘efficiency’ or ‘harmonious integration’, or at least, not as such.

She would no doubt claim that ‘efficiency’ (or at least some aspects thereof) is carried forward into the research in ‘effectiveness’ and that ‘harmonious integration’ (or at least its absence, is carried forward in the conceptualisation of ‘behaviour conflicts’, that is, which domain sub-object transformations hinder other domain sub-object transformations (see Section 6: Method for Co-ordination Design Problem Diagnosis, Stage 3)).

In contrast, Hill appears to adopt completely the Home Office’s (1994) definition of the overall task – ‘to save life, prevent escalation of the disaster, to relieve suffering, to facilitate investigation of the incident, safeguard the environment, protect property and restore normality’ (see Section 1.5.1 HCI-PMT Axioms for EMCRS, Axiom 2.2). All appear in Hill’s EMCRS domain model, so that she can rightly claim – ‘ the overall task for the EMCRS is to transform the DISASTER Object to a desired level of stability and normality’.

By directly adopting the domain definitions or indirectly working within them, Hill ensures that the EMCRS domain can be modeled by the HCI-PCMT framework (the research requirement – see Figure 2); but that the results can be communicated to domain experts (the operational requirement).  The design problems, diagnosed by the research, were discussed with the Emergency Planning Research Group at the Home Office, who agreed with their existence and importance (see Section 7: Summary and Future Work, Paragraph 2).

In summary, then, the relationship between domain definitions of worksystems and their work and research conceptualisations thereof are critical both for the conduct of the research (that is, the acquisition of design knowledge to support problem diagnosis and solution prescription) and the communication of the research results to clients, domain experts etc. This issue warrants further study and analysis. Additional illustrations of this issue can be found in the remaining Festschrift published (and submitted) papers.


However, even after the introduction of the EMCRS there are still occasions when the emergency response to disasters has been identified as being un-co-ordinated. For example, on July 7th 2005, terrorist attacks in London left 52 dead and many more injured. The report into the terrorist attacks (Anon., 2006), found that there were issues with the emergency services response, mainly due to communication problems, which led to an un-coordinated response. For example, although it states in the London Emergency Procedure Manual that a major incident can be declared by any of the emergency services, the implication being that this will be done on behalf of all the services, on 7th July all three primary emergency services declared a major incident, independent of each other. It was not clear to the reviewers as to why this happened, and also why a declaration of a major incident by one emergency service had not automatically mobilised units from all three (Police, Fire and Ambulance) Services. As a result the review states: ”We recommend that the London Resilience Forum review the protocols for declaring a major incident to ensure that, as soon as one of the emergency services declares a major incident, the others also put major incident procedures in place. This could increase the speed with which the emergency services establish what has happened and begin to enact a co-ordinated and effective emergency response”.

There have been many methods, models and frameworks developed for analysis of Emergency Management. Specifically Rogalski and Samurcay (1993) have focused on communication between the services as a means of analysing distributed decision making. The analysis allows an understanding of why one group is better than the other. The group that has a better flow of communication and distribution of roles is more efficient. Samurcay and Rogalski (1991) have also developed a Method for Tactical Reasoning (MTR) and applied it in emergency management. This method describes a decomposition of the overall task (for the class of emergency situations) into specific tasks (involved in analysis and planning), as prescribed tasks in the sense developed by Leplat (1988). The MTR provides a model of the cognitive tasks, involved in emergency management. This research allows for an understanding of emergency management behaviours, but does not relate it directly to the design of the emergency management system. Kaempf et al. (1996) studied the decision making of experienced personnel in complex command and control environments, using the recognition-primed decision (RPD) model (Klein and Woods, 1993), which depicts how experienced people make decisions in natural settings. The results of the study suggested that decision makers use recognition processes and that situation awareness is of primary concern. However, it is difficult to generalise from this study to other command and control domains, as the domain studied was very procedural in nature, and thus, other command and control settings may place different requirements on the decision makers. Other work, such as Blandford and Wong (2004) and Blandford et al. (2002) has looked at the behaviours of individual services within emergency management, but does not relate these behaviours to the other services within emergency management, and does not develop systematic models that can be directly used for design of the emergency management system.

Frameworks and models are prevalent in the HCI literature (Long, 1987; Whitefield, 1990). However, most models of interaction are task based (Wright et al., 2000). Traditional task analysis methods such as GOMS (Card et al., 1983), Hierarchical Task Analysis (Shepherd, 1989), Task Knowledge Structures (Johnson, 1992), based on observable actions may not be appropriate for analysing complex work domains (Moray et al., 1992). These methods of task analysis do not account for the variability of behaviour that is observed in complex systems (Vicente, 1990). One approach to HCI that places an emphasis on the importance of the constraints in the environment (i.e. the task or the work domain) that are relevant to the operator is an ecological one (Vicente, 1990). The framework used in the current research (the HCI-PCMT framework) has an ecological perspective, in as much as it includes a domain external to the system of concern.

Comment 4
References to ‘ecology’ and ‘ecological validity’ abound in the HCI literature. Most are consistent with natural language definitions, for example, ‘study of plants/animals/peoples/institutions in relation to environment’ (Chambers, 1983). Alternatively, ‘study of organisms in relation to their surroundings’ (Oxford Pocket, 1984). As an illustration, Flach claims that: ‘The field (Cognitive Systems Engineering) places a high value on external or ecological validity and naturalistic observations, where cognition is studied in rich semantic contexts’ (1998). The claim sets no obvious limits on the ‘external or ecological validity’, that is, the environment, as it relates to Cognitive Systems Engineering. In contrast, Dowell and Long (1989), limit the ecological environment to the domain of work. For example, their conception: ‘proposes an ecology of worksystem and domain, whereby the behaviours of worksystems are shaped by, and so reflect, their specific domains’.

Hill follows Dowell and Long (1989), as concerns her use of the concept of ecology. For example: ‘The framework used in the current research (the HCI-Planning and Control of Multiple Tasks framework) has an ecological perspective, in as much as it includes a domain external to the system of concern (Section 1, Introduction). Later, she claims: ‘It is understood that data from a real disaster would give the EMCRS model greater ecological validity, than using data from training exercises’ (Section 7).

Limiting the environment to the domain, in the manner of Hill, has the advantage that the domain is completely specified (see Figure 2, showing EMCRS Model 1).

Researchers preferring the more general concept of the environment to complete the ecological dualism, along with the worksystem, would be wise to follow her example and specify those aspects of the environment, relevant to the worksystem. Without such specification, research cannot be replicated and so validated (Long, 1997). Validation of design knowledge is a pre-requisite for HCI discipline progress (as opposed to HCI community growth – see also comments on Carroll’s paper (2010)).



This approach is similar to the work of others, for example, the Means-Ends Abstraction Hierarchy of Rasmussen and Vicente (1989). However, although the Means-Ends Abstraction Hierarchy can function as a mechanism to cope with the complexity of the natural environment, unlike the HCI-PCMT framework, no distinction is made between the work domain and the interactive worksystem, which allows for an expression of the performance of the system. The Means-Ends Abstraction Hierarchy is a also a more general framework for analysing complex HCI systems, its purpose is not specifically for modelling planning and control in multiple task work situations, and therefore it does not have a planning and control architecture. Consistent with a cognitive engineering perspective (Norman, 1986), the HCI-PCMT framework aims to model the cognitive behaviours of a ‘joint cognitive system’ (Woods and Hollnagel, 1987), considered in relation to their task ‘world’. The HCI-PCMT framework was developed specifically for analysing planning and control for multiple task work systems, and has been shown in previous case-studies to diagnose planning and control design problems (Smith et al., 1997). Thus the HCI-PCMT framework has an, albeit minimalist architecture, to accommodate such planning and control systems. The HCI-PCMT framework was also developed to analyse ‘to-be computerised systems’, and the EMCRS analysed was not computerised.

1.1. Development of design-oriented frameworks and models for HCI

The research presented in this paper is intended to constitute HCI substantive1 design knowledge, in the form of models that support diagnosis of specific design problems, and reasoning about potential solutions to these problems. Dowell and Long (1989) propose the discipline of HCI as the application of HCI knowledge, to support design practices, intended to solve HCI design problems. They identify validated engineering principles as a type of knowledge that best supports HCI practice. These principles would therefore support the design of general solutions to general classes of HCI design problems. The development of such principles represents a long-term goal for an engineering design discipline of HCI.

Comment 5
Hill reports research, which develops models and a method, as HCI design knowledge (Long, 2010), to support diagnosis of specific design problems and reasoning about potential solutions to these problems. Hill contrasts models and methods as HCI design knowledge with (HCI Engineering) Principles, as proposed by Dowell and Long (1989 and 1998). ‘They identify validated engineering design principles, as a type of knowledge, that best supports HCI practice. These principles would, therefore, support the design of general solutions to general classes of HCI design problems’. General Design Problem corresponds to Salter’s Specific Requirements Specification and General Design Solution corresponds to his General Artefact Specification. The derivation and verification relations between them are formal, as are the relations between General and Specific Design Problem and General and Specific Design Solution (see Salter (2010) – Figure 8). The development of such principles represents a long-term goal for an engineering design disciple of HCI (see Section 1: Introduction).

The contrast between these two types of HCI design knowledge, that is, models and methods in the short to medium term and principles in the longer term, raises the issue of the relationship between them. It is important, for example, whether the latter can build on the former, that is, whether Hill’s research, in some way, contributes to the development of principles. It may be that there is no relation between them. However, if the two types of design knowledge share the same conceptions (of the HCI Discipline and the HCI Design Problem) a relationship would seem possible and even plausible.


Following, my Festschrift contribution (2010), the most plausible set of relations are as follows: ‘Models and methods research’ shows promise to be carried forward into ‘principles research’, if it succeeds in specifying the models and methods themselves in terms of an HCI Design Problem (as specified by Dowell and Long (1989) in Hill’s case). It is more promising, if the models and methods also support the diagnosis of design problems (again, as in Hill’s research). It is even more promising, if the models and methods prescribe design solutions to the diagnosed problems (only informally and by way of illustration in Hill’s research). However, it is most promising, if the problems and solutions are completely specified, for principles research to attempt to identify the commonalities (and the non-commonalities) between them, to support the formulation of a principle by which the solution is formally derivable (or not) from the problem (see Salter’s (2010) Figure 8 – Design Practice Exemplars). These are all ways, in which ‘models and methods’ research can support ‘principles’ research. Hill’s work is able to provide such support; but has not been required to do so, at this point in time.


Elsewhere, work by Stork (1999) and Cummaford (2007) has made use of models and methods research to support the construction of HCI Design Principles. For example, Stork applied the MUSE (Method for Usability Engineering – Lim and Long, 1994) method, as part of ‘HCI best practice’ to help solve design problems in the domain of domestic energy management to support the formulation of initial principles. Likewise, Cummaford used ‘existing HCI design knowledge (including domain (Dowell and Long, 1989) and user models (Smith et al. 1992) and methods to specify class design problems and solutions, as part of his attempt to formulate initial principles for business-to-consumer electronic commerce transactions. Models and methods research, then, has already supported principles research. Models and methods and principles are forms of HCI design knowledge, intended to diagnose design problems and to prescribe design solutions.



Design-oriented frameworks are one form of HCI knowledge, which is both explicit and is intended to support design directly. Such frameworks provide the basis for modelling specific design problems. Their purpose is to enable designers to reason more effectively about potential design solutions. Frameworks lack the ‘guarantee’ of validated engineering principles. Instead, they support the practices of ‘specify-and-implement’. That is, practices where design proceeds through iterations of successive cycles of specification and implementation. Such frameworks support the designer in producing better specifications at an earlier stage of design, thus reducing costly iteration. These frameworks produce models of the systems under investigation, that support diagnosis of design problems, and reasoning about design solutions. For HCI knowledge to be design-oriented, it must be formulated in relation to an adequate expression of HCI design problems. In turn, an adequate expression of HCI design problems must be constructed in relation to a complete and coherent conception of the ontology of HCI; that is, a conception of those entities constituting the scope of application of the HCI discipline (Long, 1996). Dowell and Long (1989) have developed a conception of HCI as engineering (HCIE) in which they attempt to outline a general, complete and coherent ontology for HCI comprising: (i) an interactive worksystem – the tobe-designed system comprising users and computers, (ii) a domain of application – the work to be carried out, and (iii) performance – the effectiveness with which work is carried out. The framework used for the modelling described in this paper is thus based on the Dowell and Long (1989) conception.

As stated above, the research described in this paper developed such models for the EMCRS – a system that manages the response of the emergency services to disasters, that support diagnosis of EMCRS co-ordination design problems and reasoning about design solutions to these problems.

To show the development of such models this paper will first describe the EMCRS modelled. Then the background to the use of Design-oriented frameworks for such modelling will be presented. The actual framework used for the modelling, based on the Dowell and Long (1989, 1998) conception will then be described in detail in Section 3. In Section 4 the EMCRS data gathered for modelling are outlined. Section 5 describes model development through application of the framework presented in Section 3. Section 6 presents the method for co-ordination design problem diagnosis and applies the method to identify one behaviour conflict and diagnose the co-ordination design problem of cordon restrictions. The last section summarises the paper and identifies future work.

2. Domain of study

Emergency management is an example of a multi-user planning environment, which requires operators to deal with emergency situations. Controlling these situations requires the co-ordination of numerous agents, who share the various specific tasks, which fulfil the overall goal of making the situation stable. These tasks involve a number of people, often geographically distributed, working simultaneously (rather than sequentially), as a team towards the achievement of shared goals. The development of systems for emergency management, therefore, demands the analysis and modelling of co-operative work tasks, placing strong emphasis on the capture and representation of concurrent task activities, involving multiple agents.

The EMCRS has a command and control organisation with a three tier structure. The EMCRS is a general management framework, which has been agreed nationally which:

  • Defines relationships between differing levels of management.
  • Allows each agency to tailor its own response to plans to interface with the plans of others.
  • Ensures all parties involved understand their relative roles in the combined response.
  • Retains sufficient flexibility of option to suit local circumstances to enable the emergency services to interact effectively (Anon., 1994, 2001

The primary objectives of a disaster response, as declared by the Home Office are:

  • To save life.
  • To prevent escalation of the disaster.
  • To relieve suffering.
  • To protect property.
  • To safeguard the environment.
  • To facilitate criminal investigation and judicial, public, technical or other inquiries.
  • To restore normality as soon as possible.

All the different agencies should use this structure to organise their own planning procedures, so that they interface effectively with each other. The three levels are operational, tactical and strategic (sometimes referred to as bronze, silver, gold). At each level, each of the agencies has its own commander for co-ordinating the response. At the strategic level, these commanders make up a senior co-ordinating group. The operational response is carried out by each agency, concentrating on their specific tasks within their areas of responsibility, e.g. the Fire Service fighting fires. The tactical response determines the priority in allocating resources. It also plans and co-ordinates the overall response, obtaining other resources as required, for exam-ple additional fire engines. The strategic co-ordinating group has to formulate the overall policy within which the response to a major incident will be made. At the strategic level, there is one person from each emergency service. Under the EMCRS, the management of the response to major emergencies will normally be undertaken at one or more of the three levels. The degree of management required will depend on the nature and scale of the emergency.

There needs to be co-ordination at all levels of the EMCRS, so that the disaster situation is brought under control, as quickly and efficiently as possible. There needs to be co-ordination at each level within the hierarchy and between the levels. One of the main mechanisms, by which the performance of any planning system is affected, is that of coordination. Hutchins (1990) has identified important features to be accounted for in a distributed task, which ensure effectiveness:

  • Shared task knowledge – each person understands enough about each others’ work to co-ordinate effectively.
  • Horizon of observation – which allows other team members to witness other performances.
  • Multiple perspectives, which allow for activities to be observed from different points of view.

The behaviour of each member of the team is contingent on the behaviour of all the other members of the team. An action by one member will trigger an action (reaction) by another member, until the task is complete. Each member of the group has knowledge of a specific part of the distributed task, the whole group is undertaking. The co-ordination among the actions of the members of the team is not achieved by following a master procedure, instead it emerges from the interactions among the members of the team. The procedure is used as a guide to organising actions. Distribution of tasks leads to a need for co-ordination. Thus, in the case of EMCRS, co-ordination is required, because each emergency services agent only possesses a local view and incomplete information and, therefore, must co-ordinate with other agents to achieve globally coherent and efficient solutions. In emergency management, there is not only co-ordination between each agent within one group, but also co-ordination between each agency (which is made up of many single agents) on a horizontal level and vertical co-ordination between the different command levels. As stated earlier, co-ordination, or rather lack of co-ordination, has been identified as a major factor in the ineffective response of the emergency services to disasters.

The aim of this research was to attempt to diagnose these coordination problems with respect to the planning and control of the EMCRS. The emergency services response to disasters has different phases. First, there is the initial response, when the situation is usually fairly chaotic. Second, the response some time later (could be a few hours, maybe longer depending on the scale of the incident), when the situation is more stable. Last, the restoration of normality phase, when the actual incident has been brought under control, but the situation has not returned to normal. Within each of these phases, the emergency services will have different roles/tasks, that they need to carry out. During the initial response phase, the tasks being carried out by the emergency services will be their primary tasks in response to the situation, e.g. Fire Service fighting fires, Ambulance Service treating casualties. Collaboration, coordination and communication are thus, vital at the initial response stage (Anon., 2001). Co-ordination problems, occurring between services in the initial response phase, will, therefore, have more of a detrimental effect on EMCRS performance, than co-ordination problems occurring at other phases, when the tasks being carried out are not dealing with the initial effects of the situation. Data collected for use in the modelling of the EMCRS will thus need to include the initial phase as a priority. The EMCRS is thus a complex system interacting with a complex dynamic situation. There are multiple agencies, with multiple personnel, at multiple levels of command, carrying out concurrent task activities.

3. HCI planning and control for multiple task work framework

The aim of the present research was to develop models of the EMCRS that support the diagnosis of EMCRS co-ordination design problems and the reasoning about solutions to these problems. To develop such models a design-oriented framework was required, that supports modelling of the EMCRS – a distributed cognitive planning and control system, comprising more than one user, or groups of users, whose activities must be co-ordinated for effective performance. One such framework was developed for a class of HCI design problem, expressed as the planning and control of multiple task (HCI-PCMT) work in office administration a ‘to be computerised system’ (Smith et al., 1992, 1997). The office administration domains previously modelled by the HCI-PCMT framework were single user planning and control systems. Application of the HCI-PCMT framework to model the EMCRS would, thus, extend the scope of the framework to accommodate multiuser planning and control systems. The models produced would identify planning and control co-ordination design problems and thus diagnose ineffective performance.

The HCI-PCMT framework is based on a conception of HCI (Dowell and Long, 1989, 1998). The conception distinguishes the interactive worksystem, which comprises users and computers or, more generally devices/equipment, from its domain of application, constituting the work carried out by the worksystem. The effectiveness with which work is carried out, that is performance, is a function of the quality of the work (how well it is performed), and the resource costs to the worksystem (the effort, etc. of performing the work that well). Overall performance, thus, expresses whether goals have been achieved, and at what cost. A design problem is diagnosed, if actual performance (Pa) does not equal desired performance (Pd), where performance (P) is expressed as task quality (Tq), user costs (Uc) and computer (device) costs (Cc). A design solution is prescribed, if Pa is equal to Pd.

Comment 6
Throughout her paper, Hill makes liberal use of the concept of ‘problem’, for example, ‘design problem’; ‘coordination problem’; ‘coordination design problem’; and ‘inter-agency co-ordination design problem’. This use prompts consideration of how the concept of ‘problem’ is used more widely in HCI.

First, some HCI researchers make little or no use of the concept of ‘problem’. Examples to hand are the contributions of Carroll and Wild to this Festschrift (2010). Neither researcher appears to assign much, indeed if any, importance to the concept of ‘problem’, either as concerns the Discipline or a Conception of HCI.

Second, as might be expected, some researchers use the concept of ‘problem’; but only in the natural language sense of the word, for example: ‘doubtful or difficult matter requiring a solution’ (Pocket Oxford, 1984) or ‘a matter difficult of settlement or solution’ (Chambers, 1983). Dix, in his paper, writes: ‘new disciplinary roots require new methods. We have many methods in our HCI toolkit, so this does not seem to be a problem’ (Section 4). Also, in the same section: ‘The problem here is that the paper (and many in HCI) has ‘borrowed’ controlled experimentation methods from psychology…..’. Elsewhere, Salter writes: ‘The new system led to further problems as doctors receiving an offer from one residency program held off accepting until they had heard from a preferred program’ (Section 5).

Other researchers, however, conceive of ‘problem’ primarily as it relates to design and, in some cases, to a Discipline of Design. Newman, for example, identifies the first step in the engineering design process as: ‘Recognising the need for an artifice, and thus identifying a problem in computer systems design, whose solution will meet this need’. Likewise, Dowell and Long (1989) claim that: ‘Engineering disciplines apply validated models and principles to prescribe solutions to problems of design’. Also, Salter (2010) asserts that: ‘Engineering disciplines have problems of design…… (Section 1). Also, that: Disciplines of different types attempt to solve different design problems’ (Section 2). Lastly, in her abstract, Hill claims that: ‘Design knowledge supports design practice directly, as the diagnosis of design problems and the prescription of design solutions’.

As well as being conceived in terms of HCI design (or an HCI Discipline of Design), as illustrated earlier, we can further ask, together with Dowell and Long (1989): ‘What might be the nature and the form of the (design) problem being solved?’ In other words, how does a Conception of HCI conceive of a (design) problem?

Of course, such a question cannot be answered either by researchers, who eschew use of the problem concept (see Carroll and Wild earlier) or researchers, who restrict its meaning to that offered by natural language (see Dix earlier). An answer, however, can be found in the work of researchers, who use a Conception of HCI to guide their research. For example, according to Salter (Section 3 (2010)), Design Problems have two key components: ‘the requirements component and the artifact component. The requirements component is the ‘what’ of the design problem…. The artifact component represents the ‘how’ of the design problem’.

Finally, turning to Hill’s paper, she asserts: ‘A design problem is diagnosed, if actual performance (Pa) does not equal desired performance (Pd), where performance (P) is expressed as task quality (Tq), user costs (Uc) and computer (device) costs (Cc).’ By using a conception of the HCI Discipline as (engineering) design and a conception of HCI as solving design problems, Hill and Salter are able to build on the work of others, sharing the same conceptions. For example, Hill’s EMCRS models and method (as HCI design knowledge) are built on the HCI-PCMT (Planning and Control of Multiple Tasks) framework of Smith et al, (1992 and 1997), which in turn is built on Long and Dowell’s HCI Engineering Discipline Conception (1989) and Dowell and Long’s HCI Design Problem Conception (1989 and 1998). Hill’s EMCRS models and method support the diagnosis of inter-agency coordination planning and control design problems. Similarly, Salter uses the HCI Discipline and HCI Design Problem Conceptions to address the design of economic systems. Salter analyses the global financial crisis of 2007+, in terms the specification of the general problem of economic design.

Building on the work of others, as in the case of Hill and Salter, is central to the progress of the discipline of HCI. Such progress is required for the validation of HCI design knowledge as: conceptualization; operationalisation; test; and generalization (Long, 1996). The concept of design problem may have the potential to attract the consensus, which would allow HCI researchers to build on each other’s work and so to contribute to the validation of HCI design knowledge. Hill’s paper illustrates such potential.


In the Dowell and Long conception, a domain of application (or work domain) is described in terms of objects, which may be abstract or physical. Objects are constituted of attributes, which have values. The attribute values of an object may be related to the attribute values of one or more other objects. An object, at any time, is determined by the values of its attributes. The worksystem performs work by changing the value of domain objects (i.e. by transforming their actual attribute values) to their desired values, as specified by the work goal. Attributes may be affordant or dispositional. Affordant attributes are transformed by the worksystem; their transformation constitutes the work performed. Dispositional attributes are relevant to the work (they need to be used by the worksystem); but are not changed by the worksystem.

The worksystem is conceptualised as a behavioural system comprising the interacting user behaviours (supported by user structures) and computer (device) behaviours (supported by device structures). Abstract structures comprise representations and processes. Abstract representation structures refer, for example to the worksystem’s knowledge, databases or information stores. Abstract process structures refer, for example, to the worksystem’s procedures, methods or heuristics. Abstract structures support worksystem abstract behaviours, when abstract process structures, such as procedures, act on abstract representation structures, such as a database. Similarly, worksystem physical structures support worksystem physical behaviours. The HCI-PCMT framework specifies worksystem structures for the planning and control of multiple task work. These structures are expressed at both abstract and physical levels of description. Physical structures embody abstract structures and physical behaviours embody abstract behaviours. At the abstract level, the framework describes the worksystem’s cognitive structures. These comprise four process structures (planning, controlling, perceiving and executing), and two representational structures (plans and knowledge-of-tasks). These structures support the planning and control behaviours of the worksystem and are distributed across the physical users and devices/equipment. The four processes support the behaviours of planning, control, perception and execution respectively. The physical structures support the physical behaviours, but are not differentiated further by the HCI-PCMT framework, as the framework’s concern is primarily with abstract behaviours associated with planning and control.

The rationale for what to some might appear a ‘minimalist’ architecture is threefold. First, the general architecture of representations and processes is commonly assumed by Cognitive Psychology models in the information processing tradition. Secondly, the architecture was adequate to support the construction of the initial HCI-PCMT framework for the domain of secretarial office administration. Thirdly, the architecture supported the construction of models, whose form and granularity were commensurate with solving user interface design problems. The full argument for this set of structures, can be found elsewhere (Smith et al., 1997); but can be summarised as follows:

Influenced by Newell and Simon (1972), much planning research in Cognitive Science and Artificial Intelligence has tended to view plans as complete and fully-elaborated behaviour sequences, which ensure task goal achievement. This view has been undermined by research into planning in HCI. The behaviours of users, who are part of worksystems, it has been argued, cannot be regarded entirely as the output of executable plans (e.g., Suchman, 1987; Larkin, 1989; Payne, 1991) – rather they are often, at least partly, direct responses to the task environment. Within this perspective, plans need not be complete and fully-elaborated, but rather they may be partial (in the sense that they may specify only some of the behaviours to be implemented) and/or general (in the sense that some behaviours may be specified only generally and not at a level that is executable). Such plans might be more generally viewed as ‘resources’ for guiding behaviour (Suchman, 1987). Furthermore, if a plan is regarded as a resource to guide behaviour it is no longer necessary that it be limited to specifying behaviours. Rather it might, instead, specify required states of the task or conditions of the environment. Plans, which serve as resources for guiding behaviour, rather than as specifications of complete and fully-elaborated behaviour sequences, cannot ensure that goals will be achieved. This research also undermines the assumption that perception precedes planning, which precedes execution. Ambros-Ingerson (1986) argued that all planning can precede execution only when:

  1. The task environment is static – relevant changes in the task environment do not occur after the plan is complete.
  2. The task environment is simple enough to be practically modelled – the consequence of behaviours can be predicted sufficiently well to generate a complete and fully-elaborated behaviour sequence.
  3. The task environment is known – the planner’s knowledge of the task environment can be complete before planning commences.

Most task environments studied by HCI researchers do not embody these assumptions (Young and Simon, 1987). In direct contrast, they are usually dynamic, complex and partly unknown by the planner (e.g., Hollnagel et al., 1988). Execution behaviours in worksystem task environments are required to commence before plans are complete and fully-elaborated and therefore the perception, execution and planning behaviours must be temporally interleaved – having no necessarily fixed order in which to be performed.

When performing a task, a system has to exercise control; that is, it has to select the next behaviour to be carried out at each moment (e.g. Hayes-Roth, 1985). For a system, which constructs complete and fully-elaborated plans, controlling is a simple process of selecting behaviours, according to the plan and initiating their execution. However, for worksystems, which employ plans as resources to guide behaviour, some more complex control behaviour is required to select execution behaviours over time – since the selection is constrained by, rather than specified by, the plan. Furthermore, if a worksystem interleaves execution behaviours with planning and perception behaviours, controlled sequencing of these behaviours is also required.

Consistent with the preceding arguments, the PCMT framework describes the worksystems’ cognitive structures for planning and control as follows:

At the first (abstract) level of description, Plans are specifications of required transformations of domain objects and/or of required behaviours. They may be partial (in the sense that they may specify only some of the behaviours or transformations), and they may be general (in the sense that some behaviours or transformations may be specified only generally and not at a level that is directly executable). Planning behaviours, thus, specify the required domain object transformations and/or behaviours to support those transformations.

Perception and execution behaviours are, respectively, those whereby the worksystem acquires information about the domain objects and those whereby it carries out work, changing the value of the object attributes as desired. Information about domain objects from perception behaviours is expressed in the knowledgeof-tasks representation. Control behaviours entail deciding which behaviour to carry out next, both within and between tasks; but involve more than reading off the next behaviour from a complete and fully-elaborated plan.

The second level of description of planning and control structures is physical, wherein the framework describes the distribution of the abstract cognitive structures across the physically separate user and devices of particular worksystems. The framework, thus, allows the construction of alternative models of the distribution of cognitive structures across the user and devices, and so supports reasoning about allocation of function between users and devices, a major decision in design problem solutions. In the office administration domains, studied for the development of the framework, the physical worksystem was the person plus devices, but not a computer. These domains were: secretarial office administration; and medical reception. The more general notion of devices in the framework replaces the notion of a computer in the Dowell and Long (1989) conception. The use of devices (which include computers) allows the HCI framework to model work situations for which computerised support has yet to be developed. This would include the EMCRS, which at the time of analysis was not computer supported. The models of EMCRS produced by application of the framework would enable a designer to reason about design solutions including computerisation.

The outline of the HCI-PCMT framework, including its domain of application, its worksystem and its performance, is now complete. How the framework supports the analysis of multiple task work will now be outlined.

Multiple task work requires a user, as part of the interactive worksystem, to perform distinct, but overlapping tasks. Each task potentially competes for worksystem behaviours. Multiple task work represents an important concern for system designers, as performing overlapping tasks is likely to have an effect on work performance. The term ‘multiple task work’, as characterized by the framework, refers to situations, in which more than one task is carried out concurrently over relatively long and overlapping periods of time. Characterising multiple task work requires a single task to be defined. In the framework, a task is considered to be part of the work carried out in the domain of the worksystem. A task is thus conceptually distinct from the worksystem itself and its behaviours. In one of the systems previously analysed by the framework, medical reception, (see Hill et al., 1995) a task was expressed as the support of a medical case object (i.e. patients consulting with medical practitioners). The medical reception domain is an instance of multiple task work, since support is provided concurrently for multiple ongoing and temporally overlapping medical cases (i.e. for many patients together). In the EMCRS, there are multiple agencies, who need to work together towards the goal of stabilising the disaster situation. Each of the agencies involved within the EMCRS has its own set of tasks that it must carry out in order to achieve the overall goal of stabilising the disaster. These tasks are carried out independently from the other agencies; but the behaviours, associated with each of these tasks, need to be co-ordinated with the other agencies, to maximise the effectiveness of the overall EMCRS response. The work of the EMCRS can be described as the support of a disaster. Unlike, the previous systems analysed with the framework, there are obviously not multiple disasters, and thus a single task cannot be described as support for a single disaster. Rather, a single task would be each of the individual agency tasks in support of a disaster. Thus, the work of the EMCRS is multiple task, since support is provided concurrently for the multiple ongoing and temporally overlapping tasks carried out by the individual agencies in response to a disaster. This difference in the task description has implications for the application of the framework to the EMCRS, and will be one of the areas of extension for the framework, that modelling a multi-user planning system requires. These implications will be described in detail with respect to the framework axioms, (see Section 5). Extending the framework in this way, would enable application of the framework to other complex systems, where there are multiple users or groups of users carrying out independent, but concurrent tasks, that need to be co-ordinated for effective performance.

The EMCRS has more than one level of operation, in fact potentially three, (operational, tactical and strategic) depending on the characterisation of the disaster to which response is made. The HCI-PCMT framework has so far only been applied to systems with one level of operation. The HCI-PCMT framework will need to be extended to accommodate this difference.

The HCI-PCMT framework is expressed as a set of axioms,2 based on a partial and selective application of Dowell and Long’s (1989) conception for HCI. (The HCI-PCMT framework was developed for a ‘to-be computerised system’, and therefore some of the specifics of the conception which refer to computers are not applicable.) The purpose of the HCI-PCMT framework is to express design problems to aid a designer to reason about possible design solutions, in a specify-and-implement type of design practice. The axioms are described later in the paper with respect to EMCRS. A diagrammatic representation of the generic HCI-PCMT framework is shown in Fig. 1. This representation is used to apply the framework to the EMCRS.

Fig. 1. HCI-PCMT framework.

Thus, application of the framework allows for a description of the abstract and physical structures of the interactive worksystem and the abstract and physical objects of the domain of application (work). The framework defines the relationship between the abstract and physical structures of the worksystem, and the relationship between the abstract and physical objects of the domain. Performance is some function of the task quality, associated with the multiple task work carried out, and the resource costs, associated with worksystem structures and behaviours of planning and control. The framework will thus allow for a description of design problems, where actual performance does not equal desired performance.

4. EMCRS training – Exercise Scorpio

In order to develop models of the EMCRS by application of the HCI-PCMT framework, data regarding an instantiation of EMCRS were required. Ideally, such data would be from response to an actual disaster. However, these data are hard if not impossible to access, and also difficult to make direct observations from. There are various specialist training centres in the UK for the emergency services. However, there is only one centre where multidisciplinary training is provided – The Cabinet Office Emergency Planning College at Easingwold (formerly the Home Office Emergency Planning College). The aim of the college is to promote and sustain emergency preparedness within the United Kingdom through the concept of Integrated Emergency Management. Many different training exercises are run at the centre, that cover all aspects of emergency planning. The exercise where the data were gathered was the Emergency Services Seminar on Inter-Agency Response to Disaster. The aim of this seminar was to provide an opportunity for emergency services’ personnel, who may have a role to play in the dissemination of best practice at the operational, tactical and strategic command levels, to study problems which might arise from major civil emergencies with particular reference to the need for a co-ordinated response. The information regarding the exercise – Exercise Scorpio, made it clear that it was the most appropriate of all those run by the college, for gathering EMCRS data. The data were provided by two stagings of this exercise. The trainees were members of the emergency services and local authority emergency planning officers. There were 60 trainees taking part in each exercise. The emergency service personnel were brought together in multi-agency groups, called syndicates, to discuss Exercise Scorpio. These syndicates, were pre-selected, i.e. the members had applied to attend the seminar as a group. Syndicates comprised Police, Fire, Ambulance and Local Authority personnel from the same district, county or region. The exercise required the trainees to describe their response to Exercise Scorpio from initial response to the restoration of normality. There are various well defined phases in response to the disaster scenario, which involve different worksystem configurations and different worksystem behaviours. In the model, only one worksystem configuration and its behaviours are modelled – that of the initial response phase. This phase is considered critical, since co-ordination problems at this phase can have most serious effects on subsequent disaster stability.

4.1. Exercise Scorpio narrative

Newford is a market town in the county of Crownshire. The main town centre is built around the main A338 which bisects the town in a north/south direction. In the centre of the town a railway, carried on an embankment and bridge, runs directly across the town from east to west. From the railway bridge, in a northerly direction, the A338 is inclined and at the bottom of the incline is a canal with moorings for canal boats. This is a very busy holiday waterway and is a popular stopping point.

At approximately 0930 h on a weekday during school term time, a tanker train en-route from a refinery to an airport fuel depot is derailed whilst passing over a railway bridge.

The bridge which is a steel Victorian structure, carries the railway over the A338 which provides the main access into the town centre. It is market day and there are numerous market stalls set up on the side of the roadway on either side of the bridge. The market and town are a popular destination for locals and visitors from out of the town area, including foreign citizens on sightseeing tours through the area. There are a number of housing developments behind the shops in the High Street each side of the railway bridge and a nursery school with 60 toddlers is sited approximately 400 m away. A cottage Hospital with 30 beds is some 500 m to the south east of the bridge and a primary school with 200 pupils some 800 m to the south.

The train consists of a diesel electric locomotive and eight tank cars, each fully loaded with 100 tonnes of AVTUR Aviation Fuel (SIN 1863 with an emergency action code 3 (Y)E). During the derailment one of the tank cars is ruptured and aviation fuel flows down the sides of the embankment onto the roadway and into adjoining properties. Flammable vapours from the fuel have been ignited by an open gas burner from a catering caravan.

At the time the explosion occurred, a tourist bus was passing beneath the railway bridge. The bus is carrying 45 tourists of whom 25 are Japanese and German nationals.

The explosion has created severe structural damage to the railway bridge, premises adjacent to the bridge in an approximate 30 m radius and has created major leaks in two of the other tank cars. Structural damage of a moderate nature has occurred within an approximate 100 m radius. At least 50 people have been killed, including some of the foreign tourists. Many people have received burns from the flashover of the explosion and numerous people are trapped and injured in properties, beneath the bridge the structure and in vehicles on the roadway. A number have also been contaminated by aviation fuel. There are numerous fires in the area.

The leaking fuel has run down the road incline to the north of the bridge and is entering the canal and watercourses at the bottom of the incline. The river flows from east to west but there is no particular flow on the canal. The wind is north westerly Force 2–3. There are several barges used for residential purposes moored on the canal.

Early information from witnesses suggests youths have been seen running from the section of rail track where the derailment took place and that vandalism may be responsible for the derailment.

No recording device could be used for gathering data as each syndicate was located separately. Therefore, during the syndicate discussions data were collected through note taking by the researcher. These notes were an aide memoire for the researcher. All the syndicates were then brought together and asked to present their responses to the group as a whole. General information from these presentations was recorded in bullet-point form on a printable white-board. These records were printed for the researcher.

For each of the emergency services, the trainees were asked to describe: what their roles would be for the scenario; what their response would be to the scenario; what problems they would face; what problems the other services would face; and what potential conflicts there would be with the other services. The raw data recorded required explanation, as many aspects of the Emergency Service personnel responses were couched in language specific to the Emergency Services and would therefore be unclear or uninformative for a naïve reader. The researcher thus ‘expanded’ the data to express as much information as possible. This expansion was based on: the discussion within the syndicates; from further discussion within the seminar between the Emergency Services trainees and their trainers; from Emergency Services planning documentation and from information given by the Home Office Emergency Planning Research Group. Data were collected at two different stagings of Exercise Scorpio.

5. EMCRS model development

The EMCRS models were constructed by application of the HCIPCMT framework axioms and representation to the data collected from two stagings of Exercise Scorpio. The application of the HCIPCMT framework axioms to EMCRS will extend the framework to accommodate the EMCRS. Section 5.1 will present the HCI-PCMT framework axioms applied to EMCRS data. The HCI-PCMT framework representation was applied to the two datasets to produce two different EMCRS models. These models were then combined to produce EMCRS Model 1 which is presented and described in Section 5.2.

To reiterate to aid understanding for the reader, the HCI-PCMT framework makes a distinction between the interactive worksystem (users and computers/devices) and its domain of application or work domain.

5.1. HCI-PCMT axioms for EMCRS

5.1.1. Axiom 2.1 HCI-PCMT EMCRS design problems

HCI-PCMT EMCRS design problems and their possible solutions, generated by specify-and-implement design practice, entail the specification of the implementable3 planning (structures and) behaviours and control (structures and) behaviours of the emergency service personnel and emergency service devices of the worksystem, such that when they interact with the perception (structures and) behaviours and execution (structures and) behaviours of the emergency service personnel and emergency service devices, they provide support for a disaster, such that the actual level of performance falls within some desired level of performance.

5.1.2. Axiom 2.2 EMCRS domain: multiple task work

The domain is described at both an abstract and a physical level. At the highest level of description (Abstract level 2) is the Disaster object. This Disaster object is defined at Abstract level 2, the highest level. The attributes and values for the Disaster object were conceptualised as stability and normality, with values along a continuum. Thus, the overall task of the EMCRS is to transform the Disaster object to a desired level of stability and normality. The performance of the EMCRS worksystem is expressed by the transformation of the Disaster object’s attribute values. Each task carried out by the worksystem transforms the attribute values of the disaster object. These attribute values change by manipulation of the values of the attributes of the sub-objects of the domain. These sub-objects’ attribute value changes are affected by the sub-tasks of the EMCRS, which are the individual agency tasks (also the multiple tasks in EMCRS). Each of these sub-tasks will have associated domain sub-object transformations – sub-transformations. The required transformation of the Disaster object can be divided into a number of sub-transformations, concerning particular sub-objects and their attributes. The attribute normality was conceptualised from the notion that at the beginning of the disaster scenario the ‘disaster’ is chaos, and the work of the EMCRS is ultimately to restore normality, i.e. to bring the disaster under control. Thus, the more desirable the level of normality the better the performance of the EMCRS. The second attribute – stability was conceptualised through an understanding of the expected overall performance of the EMCRS worksystem – that of stabilising the disaster (preventing further loss of life and containing fires and other hazards). Both of these attributes’ values are changed by the transformation of the sub-object attribute values.

The other abstract objects, which are sub-objects of the disaster object, were conceptualised from: the primary objectives of the EMCRS (see Section 2); the primary roles/tasks for the emergency services (Anon., 1994); information from the exercise narrative; and the data. The sub-objects of the domain: the Lives sub-object; Disaster Character sub-object; Disaster Scene sub-object; Property sub-object, Environment sub-object and Emergency Service sub-object are at a lower abstract level of description – Abstract level 1. At the physical level of description, the abstract sub-objects of the domain are realised as physical objects. Abstract level 1 objects have realisation attributes whose values specify the physical objects of their realisation. These three levels are the same as those for the office administration domains. Vertical relationships exist between the values of attributes at different levels of description. The realisation relationship between Abstract level 1 objects and Physical level objects is a many-to-one relationship. The value of physical object attributes determine through emergence the values of Abstract level 1 attributes. In turn, the values of attributes of the Disaster object (Abstract level 2) are determined by an emergence relationship from the values of attributes at Abstract level 1 – the sub-object attribute values. Horizontal relationships exist. There is a relationship between the values of the attributes at the same level of description. For example, at Abstract Level 1, the Disaster Scene sub-object attribute scene containment value contained will require the Lives sub-object emergency services personnel safety to have a value of equipped. A task is the required state transformation of the Disaster object, including all lower level transformations of the associated sub-objects. As there is only a single Disaster object, at the highest level of description, multiple task work is that domain work in which, at the highest level of description, the Disaster objects attributes are undergoing independent, but temporally overlapping transformations. This HCI-PCMT extension is to accommodate a multi-user planning system. (The EMCRS domain thus, contrasts, with the office administration domain where there are multiple objects at the highest level of description.)

5.1.3. Axiom 2.3 EMCRS worksystem: planning and control behaviours and structures

Four types of abstract behaviour are generic to the worksystem and undifferentiated between the users and devices. These behaviours are planning, control, perception and execution. The four types of abstract behaviour are supported by abstract structures, also undifferentiated between users and devices. These abstract structures comprise four types of process, corresponding to the four types of behaviour. That is, a planning process, a controlling process, a perceiving process, and an executing process. There are two types of representations: a plan representation and a knowledge-of-tasks representation. The EMCRS abstract worksystem is defined in terms of these abstract cognitive structures. The physical worksystem structures were identified from analysis of the data, from information about EMCRS structures, and information about the required personnel and resources for particular worksystem behaviours (specified in the roles/tasks of the different services). Thus, from information on the EMCRS, we have commanders at the tactical and operational levels of control. From information on roles/tasks for the emergency services, and from the data, one role of the Police Service is the preservation of the scene for evidence and enquiries. Preserving the scene will require Police personnel to manage the scene. All the physical structures required for model diagnosis of design problems from the identified conflicts are represented in the model. These abstract and physical structures are shown in Fig. 2.

Fig. 2. EMCRS physical and abstract structures.

The behaviours associated with these structures are as follows: Perception behaviours are those, whereby the worksystem acquires information about Property, Lives and other domain objects, such as their risk status, and records these values. The states of the domain objects form the contents of the Knowledge-of-tasks representation. Perception behaviours update the contents of the Knowledge-of-tasks representation, based on the reading of the domain, for example that there are properties at risk. Execution behaviours are those which carry out the work of the worksystem by transforming the values of the domain object attributes values directly; for example, treating injured survivors at the scene transforms the Lives sub-object attribute survivor status from untreated to treated. These execution behaviours will in turn transform the Disaster object to a more desired level of stability along its continuum. Planning behaviours are those that specify what and/or how tasks will be accomplished in terms of required object state transformations and/or required worksystem behaviours, for example, that the site should be declared a crime scene, which requires Police personnel to manage it. Control behaviours select which behaviours should be carried out next, based on the contents of the plan and Knowledge-oftasks representation. A plan representation structure embodies the plans used in the combined response. These structures are distributed across the different levels of the worksystem, i.e. strategic, tactical and operational.

5.1.4. Axiom 2.4 EMCRS performance

Performance is some function of: the task quality associated with the multiple task work (for example, lives saved, fires contained) and the resource costs associated with the worksystem planning and control behaviours (for example, plans correct, firemen in place). (As above resource costs are not differentiated between the user and devices, also resource costs are specific to the planning and control worksystem structures and behaviours.)

All the HCI-PCMT axioms have now been re-expressed for the EMCRS. These axioms and the HCI-PCMT framework representation were applied to the data from the training exercises to produce EMCRS models. Details of the how the models were constructed will not be presented here as the remit of the current paper is to show how the models can be used for design problem diagnosis.4 Model 1 is the combined model from both datasets.

5.2. EMCRS Model 1

Fig. 2 shows EMCRS Model 1, the model constructed by application of the HCI-PCMT framework to the combined datasets 1 and 2. EMCRS Model 1 shows all the abstract and physical structures of the worksystem identified from both datasets, on the left handside of the diagram. At the abstract level, the three tier structure of the EMCRS, operational, tactical and strategic is depicted (but interactions within and between levels are not shown). These abstract structures are distributed across the physical worksystem structures. This distribution is not shown here, due to the limitations of the representation. The abstract structures representation is the same as that shown in Fig. 1. The physical level shows all those structures that have been identified as necessary to inform the abstract structures of the worksystem for the conflicts identified within both datasets. On the right-hand side, the domain objects, attributes and values are shown, from both datasets, both abstract and physical. The physical level objects attributes and values are not shown in full, as the representation shown here cannot support this. (For further information see Hill, 2005.) The links, between the abstract sub-objects and the physical objects, shown with a dotted line define the abstract to physical realisation relationship. The realisation relationship has a one-to-many mapping. The full lines between the Disaster object and the other sub-objects define a part-of relationship. The attributes with a star (*) are dispositional, that is they need to be perceived by the worksystem; but are not changed by it.

Although a strategic level of command is represented in Model 1, this intent is for completeness of the EMCRS representation. The structures of the strategic level are not referred to in the model descriptions. The reason is because, although a strategic level of command was set up in the exercise and so is, thus, included in the representation, this command level is not activated in the initial response phase to the exercise. The data for the modelling are only from the initial response phase, and therefore do not refer to the strategic command level. It is often the case that a strategic level of command is not activated in major incidents, until later in the response, or sometimes not at all, if it is decided that it is not required.

The EMCRS Model 1 is intended to be a model for diagnosing planning and control co-ordination design problems of the EMCRS, and offering up potential solutions to these design problems. A method was developed to aid in the use of the model for diagnosis. Thus, once constructed, Model 1 was used to diagnose EMCRS coordination design problems, through application of this method. A planning and control co-ordination problem is diagnosed if actual performance does not equal desired performance, where performance is expressed as a function of task quality and resource costs to the system, i.e. performance expresses whether goals have been achieved and at what cost. The method therefore guides the identification from the model of the planning and control behaviours of the interactive worksystem associated with a given task and the corresponding desired domain object transformations, such that the performance of the system for this particular task can be expressed. Being able to identify where (at a planning and control level) within the system a co-ordination design problem is occurring enables better reasoning about potential design solutions to these problems. The next Section describes the method for co-ordination design problem diagnosis.

6. Method for co-ordination design problem diagnosis

Application of the method and the diagnosis of one co-ordination design problem will now be described (see Table 1).

6.1. Method stage 1 – identifying potential conflicts

The training scenario questions included one on inter-agency conflicts. From the data recorded in responses to this question, five sets of conflicts were identified. This section will describe one of these conflicts as identified in the data.

Conflict 2 Cordon restrictions – due to information in the Exercise Scorpio narrative, regarding structural damage to buildings and a number of fires at the scene, the Fire Service set up an inner cordon to contain the scene. The Fire Service are responsible for the safety of all personnel within the cordon. Access is restricted to those with regulation safety equipment. The Ambulance Service need access to locate casualties and either treat them at the scene, or transport them to hospital. The Ambulance Service do not have regulation safety equipment and are not allowed access to the casualties. The Fire Service task of containing the scene conflicts with the Ambulance Service task of locating and treating casualties.

Having identified the behaviour conflict, stage one of the method is now complete. The next stages of the diagnosis method are now applied to the identified conflict, to diagnose co-ordination design problems. Co-ordination design problems are diagnosed, if actual performance does not equal desired performance.

6.2. Method stage 2

The behaviour conflict arose as follows: The Fire Service operational commander (physical structure) carries out perception behaviours that update his knowledge-of-tasks with the information that there are structurally damaged buildings, fires and leaking hazardous fuels. He then carries out control behaviours that direct him to consult the major incident plan. The plan specifies that the Fire Service is responsible for setting up an inner safety cordon, when there are hazards and dangers at the scene, and maintaining the safety of all those within the scene. Based on this plan, and the knowledge-of-tasks (about the fires etc.), the operational commander carries out control behaviours that direct him to consult the operational plan for setting up of a cordon. The operational plan gives guidance for cordon set-up and regulations. The operational commander then carries out control behaviours that direct him to carry out planning behaviours, based on the operational plan and the knowledge-of-tasks. The planning behaviour specifies how the inner cordon should be set-up and what the regulations are for entering it. The operational commander then carries out control behaviours that direct him to carry out an execution behaviour of setting up the cordon. This execution behaviour is carried out by the operational personnel (firemen) setting up the cordon and maintaining specified safety regulations. This physical object manipulation transforms the abstract Disaster Scene sub-object’s attribute scene containment from un-contained to contained. Thus, transforming the Disaster object attribute of stability to a more desired level along its continuum. (At the same time, other operational firemen and their fire equipment are controlling the fire and stabilising buildings, transforming the attributes of the Property and Disaster Character sub-objects, which are again transforming the Disaster objects stability attribute towards its desired level.)

Method Stages Action Example for Clarification
1 From data, identify tasks carried out by each agency in response to the scenario, where there are potential conflicts Set-up of inner cordon by the Fire Service; access to casualties for triage without regulation safety equipment by the Ambulance Service
2 Use Model 1 to describe the behaviours associated with each task and the corresponding desired domain sub-object transformations Desired domain sub-object transformations are those transformations that would be carried out, if an agency’s behaviours are not hindered. For the above example, one desired domain sub-object transformation for the Ambulance Service would be: Lives sub-object attribute survivor triage status from untriaged to triaged
3 Identify behaviour conflicts i.e. which domain sub-object transformations will hinder other domain sub-object transformations From the above example the Fire Service behaviours of transforming the Disaster Scene sub-object attribute scene containment from un-contained to contained have hindered the Ambulance Servic behaviours and corresponding domain sub-object transformations
4 Use Model 1 to identify whether other domain sub-object transformations that will be hindered as a ‘knock on effect’ from the initial conflict behaviour For example, the Ambulance Service not being able to transform the Lives sub-object attribute survivor triage status from untriaged to triaged will mean that the Lives sub-object attribute survivor treatment status cannot be transformed from not treated to treated. Also, as the Ambulance Service cannot access the casualties, the Fire Service will have to move the casualties to the edge of the cordon to enable triage to take place. In so doing, the Fire Service will reduce their fire fighting and property protection behaviours, as personnel will need to be taken away from these tasks to carry out rescue behaviours and will therefore not be able to transform the Disaster Character sub-object attribute fire status from uncontrolled to controlled, and the Property sub-object attributes of buildings/vehicles status from at risk to not at risk
5 Identify the performance effect of the hindered domain sub-object transformations by referring to the overall common objectives and priorities of the EMCRS (i.e. to save life, to prevent escalation of the disaster, etc.). The primary priority for all services is to save life. Therefore, hindering any domain sub-object transformation that reduces life saving by the EMCRS will have the greatest impact on performance In the current example, hindering triage and subsequent treatment transformations by the Ambulance Service, of the Lives sub-object will greatly affect the performance of the EMCRS with respect to the primary priority of saving life. Reducing the fire fighting and property protection behaviours by the Fire Service will have an effect on the secondary priority of preventing escalation of the disaster. Thus, Model 1 gives a performance expression of actual performance being less than planned/ desired performance, as a performance deficit, is shown for both agencies

Table 1 Method for co-ordination design problem diagnosis.

The operational commander then carries out control behaviours that direct him to inform the tactical incident officer of the inner cordon set-up. (Some kind of internal communication behaviour is carried out to inform the incident officer about the cordon set-up.) The tactical incident officer (and his communication equipment) then carries out perception behaviours, which update his knowledge-of-tasks about the inner cordon set-up. The tactical incident officer then carries out control behaviours that direct him to consult his plan to assess the resources required for the setup. He then carries out planning behaviours to specify the resources required for this task.

At the same time, the operational Ambulance Senior officer (tactical level), (with his communication equipment) is carrying out perception behaviours that update his knowledge-of-tasks with the information that there are a number of casualties at the scene. He then carries out control behaviours that direct him to consult his major incident plan. According to the plan, casualties must be triaged and then either treated at the scene and/or transported to hospital. He then carries out control behaviours that direct him to carry out planning behaviours to specify in the operational plan what personnel are required to triage, treat and/or transport the casualties. Based on this plan and the knowledge-of-tasks, he then carries out control behaviours to direct the execution behaviours of triaging, treating and/or transporting casualties. These execution behaviours are carried out by the Ambulance operational personnel for triage and treatment with their Ambulances for transport. It is the manipulation of the physical casualties, which transforms the abstract Lives sub-object attributes survivor triage status from untriaged to triaged, survivor treatment status from not treated to treated and survivor transport status from not transported to transported. In turn these sub-object transformations, change the Disaster object’s desired level of stability.

6.3. Method stage 3

However, the Ambulance operational senior officer (tactical level, and his communication equipment) has not carried out perception behaviours that update his knowledge-of-tasks, that the scene is now contained, and regulation safety equipment is required to enter it. Therefore, when the Ambulance personnel attempt to carry out their execution behaviours, they do not fulfil the proper safety requirements, which would allow them to enter the inner cordon. Therefore, the execution behaviours of triaging, treating and/or transporting casualties cannot be carried out. Thus, they cannot transform the abstract Lives sub-object attributes and so cannot transform the Disaster object to a more desired level of stability. Thus, a behaviour conflict has been identified. Identifying behaviour conflicts enables co-ordination design problem diagnosis.

6.4. Method stage 4

The primary objective of EMCRS is to save life. In order to try to increase the desired level of stability of the Disaster object, the Lives object attribute values must be changed. Therefore, the Fire Service must carry out rescue execution behaviours to move the survivors to the edge of the inner cordon, so that the Ambulance Service can carry out their execution behaviours and, thus, increase the stability of the disaster object. However, the Fire Service carrying out rescue execution behaviours will decrease the resources available for performing the execution behaviours of controlling the hazard, thus decreasing the effectiveness of the response to the secondary objective of preventing escalation of disaster. The outcome is that the performance of the EMCRS is reduced even further.

6.5. Method stage 5

The Fire Service behaviours of containing the scene have conflicted with the Ambulance Service behaviours of triaging, treating and/or transporting casualties, and result in a behaviour conflict. This behaviour conflict results in a co-ordination design problem, which may relate to reduced overall EMCRS performance, either through hindered goal achievement (e.g. lives not saved) or through unacceptable system resource costs (e.g. excessive firefighter workload). The model diagnoses an EMCRS co-ordination design problem as actual overall performance being less than desired performance with respect to the EMCRS common objectives. This co-ordination design problem relates to the common EMCRS objectives, i.e. to save life (casualties not rescued); to prevent escalation of disaster; (fire not contained). Model 1 describes a performance deficit, related to hindered goal achievement and unacceptable resource costs for the Ambulance and Fire Services. Containment of the scene with safety requirements by the Fire Service reduces casualty triage and treatment (life saving) by the Ambulance Service. The Ambulance Service having to wait to treat casualties will increase their treatment workload. The Fire Service scene entrance safety requirements excluding the Ambulance Service, reduces Fire Service fire containment, as they have to rescue casualties and move them to the edge of the scene. The Fire Service workload will thus increase.

A design problem diagnosis by the EMCRS model has been described. To authenticate this design problem diagnosis, a potential design solution to this problem will now be suggested. The execution behaviours of the Fire Service (setting up an inner cordon and maintaining specified safety regulations) have been identified as part of the cause of the identified design problem. How these execution behaviours came about can be identified by the model. The behaviours, that affected the Fire Service execution behaviours of inner cordon set-up, were the planning and control behaviours of the operational commander. Planning behaviour, as specified in the model, is based on the plans and the information in the knowledge-of-tasks representation (in this case, for example, structural damage and many fires at the scene). The plan which the operational commander consulted, should have specified that set-up of the inner cordon should not be progressed without the knowledge of the Ambulance Service (Chief and Assistant Chief Fire Officers’ Association, 1994). The Fire Service operational commander, thus, had an inappropriate representation of the plan, which has caused inappropriate planning behaviours, that have contributed to the design problem. Now that it has been identified, where in the planning system the problem is occurring, reasoning about potential solutions to this design problem, are possible. A potential solution is to enable adequate training of the procedures specified in the operational plans, such that inappropriate planning behaviours are not carried out, and such that actual performance equals desired performance, for inner cordon set-up by the Fire Service, i.e. the set-up is as desired and with acceptable resource costs.

The Ambulance service execution behaviours of accessing casualties for triage and treatment are identified as part of the cause of this co-ordination design problem. These execution behaviours are affected by the planning and control behaviours of the Ambulance operational officer. Planning behaviour as specified in the model, is based on the plans and the information in the knowledge-of-tasks representation (in this case, for example, casualties and an inner cordon). The plan that the Ambulance Service officer consulted, should have specified that liaison should take place with the Fire Service about what safety equipment is required for entering the cordon (The National Health Service Ambulance Service, 1994). The Ambulance Service operational officer had an inappropriate representation of the plan, which has caused inappropriate planning behaviours, which have contributed to the design problem. A potential solution is to enable adequate training of the procedures specified in the operational plans, such that inappropriate planning behaviours are not carried out, and such that actual performance equals desired performance, for Ambulance Service triage and treatment of casualties, i.e. triage and treatment are as desired with acceptable resource costs.

7. Summary and future work

This paper has presented research, constituting HCI substantive design knowledge, in the form of models that support diagnosis of design problems and reasoning about solutions to these problems.

Comment 7
There is general agreement that the requirements phase is the foundation upon which the rest of the system development life-cycle is built (Somerville, 1989). Requirements can be divided into different categories – functional and non-functional (IEEE, 1984); also vital and desirable (BSI, 1986). More specific types of requirements may also be identified, including organisational; user interaction; and interface (Denley, 1999). Of concern here are User Requirements (Carlshamre and Karlsson, 1996), because although part of the initial phase of the system development cycle (Newman, 1994), they do not appear to include, explicitly at least, the concept of design problem as such, as referenced here by Hill (although they do not exclude it explicitly either). The omission is important, because Hill is clear, that her models and method are intended to: ’Support diagnosis of specific design problems and reasoning about potential design solutions’ (Section 1.0). The diagnosis of design problems and the reasoning about potential design solutions are performed by designers, as part of their practice, by which design proceeds through iterations of successive cycles of specification and implementation. The question then arises as to what is the relation between user requirements and design problems?

One possible relation is that user requirements and design problems are one and the same thing. That is, there is no difference between them. Although it is not totally clear, Newman (1994) might be understood as taking this view: ’Recognising the need for an artifice, and thus identifying a problem in computer systems design whose solution will meet this need (the initial stage of the engineering design process)’. This view, however, is rejected. Following the HCI Discipline and HCI Design Problem conceptions, in the manner of Hill’s research, a design problem occurs, when actual performance, expressed as Task Quality, User Costs and Computer Costs (see earlier) does not equal (is usually less than) desired performance, expressed in the same way. In contrast, user requirements have no such expression or constraints, even allowing user requirements to conflict.

This difference indicates that user requirements and design problems are not one and the same concept. Rather, it suggests that design problems can be expressed as (potential) user requirements, but not vice versa. Salter appears to agree with this asymmetric relationship, although his terms differ. The Specific Requirements Specification (‘design problem’) is an abstraction over the Client Requirements (‘user requirements’). The Specific Artifact Specification (‘design solution’) is an abstraction over the Artifact. The Client Requirements/Artifact relationship is derived and verified empirically. The Specific Requirements Specification/Specific Artifact Specification is derived and verified formally.

Whatever the terms used, however, the general point for HCI research is that differences between User Requirements and Design Problems need to be both explicit and clear.


This paper has described the development of diagnostic models of the EMCRS, through application of the HCI-PCMT framework to data from EMCRS training exercises. The HCI-PCMT framework was based on the Dowell and Long (1989, 1998) conception of HCI. The scope of the HCI-PCMT framework needed to be extended in order to be applied to the EMCRS. The HCI-PCMT framework, as shown Fig. 1, has a representation and a set of axioms for producing diagnostic design models. The framework axioms for EMCRS have been presented in Section 5. The EMCRS axioms address some of the differences in nature of the EMCRS and the other domains previously modelled by the HCI-PCMT framework. The EMCRS axioms are considered to be extensions to the HCI-PCMT framework. The most important EMCRS axiom relates to how to describe a task and its sub-tasks. These descriptions have important implications for the characterisation of multiple task work and subsequent identification of behaviour conflicts exhibited by the data. Thus, the EMCRS multiple tasks are the individual agency tasks, which are identified as sub-tasks of the domain. These sub-tasks carry out sub-object transformations in the domain, which affect disaster object transformations. Behaviour conflicts are identified, when sub-objects are not transformed as desired. Behaviour conflicts are diagnosed as co-ordination design problems by the EMCRS model. Without the EMCRS axiom extensions co-ordination design problem diagnosis would prove difficult, if not impossible.

A diagnosis method for identifying co-ordination design problems using the EMCRS Model 1 has been presented and then applied to identify one co-ordination design problem – cordon restrictions. However, this method is at an early stage of development and must be further developed for operationalising and testing. Nevertheless, it has been applied in the current research, albeit by the method developer, and thus, has been shown to facilitate in EMCRS model diagnoses. Future research would develop this method for operationalisation, testing, generalisation and so validation. Within the original research five co-ordination design problems have been diagnosed using this method. It is realised that without validation with further examples there is a question about the generalisability of these design problems. However, these diagnosed design problems were discussed with the Emergency Planning Research Group at the Home Office, who agreed with their existence and importance. The EMCRS data gathered for this research were from training exercises. It is understood that data from a real disaster would give the EMCRS model greater ecological validity, than using data from training exercises. People with access to such data (for example, senior emergency service training and research personnel) should however, be able to apply the current framework to such data, and produce models that would support co-ordination design problem diagnosis. However, due to the complex nature of the EMCRS, data at any lower level of description, than presented in the training exercises, would have been very difficult to analyse effectively. Also, the EMCRS is a management system for co-ordination of the planning and control in response to disasters. Thus, the EMCRS is specified at a high level, with respect to the operational, tactical and strategic levels of command. The EMCRS does not specify within a service how each individual person should co-ordinate with respect to their individual agency roles. The training exercises, where the EMCRS data were gathered, were set-up specifically to train the emergency service officers in how to use the EMCRS for the management of response with respect to operational, tactical and strategic levels of command. Thus, the trainees were all emergency service officers, and not operational level personnel. The exercise data were thus viewed as appropriate for modelling the EMCRS, for planning and control of the different command levels for disaster response. The aim of the research was to model the EMCRS to diagnose design problems, but more specifically planning and control co-ordination design problems. Thus, again data at this level of detail were considered appropriate for meeting the current aims. Future work would however, involve validation of the EMCRS model by application to data from an actual disaster.


The research presented in this paper was carried out within a PhD supervised by Professor John Long, and second supervised for the last year by Professor Ann Blandford. This work was part funded by the Home Office Emergency Planning Research group under the EPSRC CASE scheme. I would like to thank Chris Johnson and the two anonymous reviewers for their constructive comments in the revision of this paper. Thanks also go to the special issue editors for pointing me in the right direction on a number of issues.


Ambros-Ingerson, J.A., 1986. Relationships between planning and execution. Quarterly Newsletter of the Society for the Study of Artificial Intelligence and Simulation of Behaviour 57, 11–14.

Anon., 1994. Dealing with Disaster, second ed. Home Office Publication, London (HMSO).

Anon., 2001. Dealing with Disaster, third ed. Cabinet Office Publication, Liverpool, Brodie.

Report of 7 July Review Committee (2006) Greater London Authority. <www.london.gov.uk/assembly/reports/7july/report.pdf>.

Blandford, A., Wong, W., 2004. Situation awareness in emergency medical dispatch.

International Journal of Human-Computer Studies 61 (4), 421–452.

Blandford, A.E., Wong, B.L.W., Connell, I., Green, T.R.G., 2002. Multiple viewpoints on computer supported team work: a case study on ambulance dispatch. In: Faulkner, X.,

Finlay, J., Détienne, F. (Eds.), People and Computers XVI: Proceedings of HCI’02. Springer, pp. 139–156.

Card, S.K., Moran, T., Newell, A., 1983. The Psychology of Human Computer Interaction. Lawrence Erlbaum, Hillsdale, NJ.

Chief and Assistant Chief Fire Officers’ Association, 1994. Fire Service Major Incident Emergency Procedures Manual. CACFOA Services Ltd, Tamworth.

Dowell, J., Long, J., 1989. Towards a conception for an engineering discipline of human factors. Ergonomics 32 (11), 1513–1536.

Dowell, J., Long, J., 1998. Conception of the cognitive engineering design problem. Ergonomics 41 (2), 126–139.

Emergency planning college document, 1995. Management Levels in Response to a Major Incident. The Principles of Command and Control.

Fennell, D., 1988. Investigation into the King’s Cross Underground Fire. Department of Transport, London (HMSO).

Hayes-Roth, B., 1985. A blackboard architecture for control. Artificial Intelligence 26, 251–321.

Hidden, A., 1989. Investigation into the Clapham Junction Railway Accident. Department of Transport, London (HMSO).

Hill, R., 2005. Diagnosing Co-ordination Problems by Modelling the Emergency Management Response to Disasters. Unpublished PhD thesis, University of London. Hill, B.,

Long, J.B., Smith, W., Whitefield, A.D., 1995. A model of medical reception— the planning and control of multiple task work. Applied Cognitive Psychology 9, 81–114.

Hollnagel, E., Mancini, G., Woods, D., 1988. Cognitive Engineering in Complex Dynamic Worlds. Academic Press, London. Hutchins, E., 1990. The technology of team navigation. In: Galegher, J., Kraut, R., Egido, C. (Eds.), Intellectual Teamwork. Lawrence Erlbaum, Hillsdale, NJ.

Johnson, P., 1992. Human-Computer Interaction: Psychology, Task Analysis and Software Engineering. McGraw-Hill, London. Kaempf, G.L., Klein, G., Thordsen,

M.J., Wolf, S., 1996. Decision making in complex naval command-and-control environments. Human Factors 38 (2), 220–231. Klein, G.A.

Woods, D.D., 1993. Conclusions: decision making in action. In: Klein, G., Orasanu, J., Calderwood, R., Zsambok, C. (Eds.), Decision-Making in Action: Models and Methods. Ablex 405-411, Norwood, NJ.

Larkin, J.H., 1989. Display-based problem solving. In: Klahr, D., Kotovsky, K. (Eds.), Complex Information Processing: the Impact of Herbert A. Simon. Lawrence Erlbaum, Hillsdale, NJ.

Leplat, J., 1988. Methodologie von Aufgabenanalyse und Aufgabengestaltung. Zeitsch-rift fur Arbeits-und Organisationpsychologie 1, 2–12.

Long, J., 1987. Cognitive ergonomics and human computer interaction. In: Warr, P. (Ed.), Psychology at Work. Penguin, Harmondsworth. Long, J., 1996. Specifying relations between research and the design of human computer interactions. International Journal of Human Computer Studies 44 (6), 875–920.

Moray, N., Sanderson, M., Vicente, K., 1992. Cognitive task analysis of a complex work domain: a case study. Reliability Engineering and System Safety 36, 207–216. Newell, A., Simon, H., 1972. Human Problem Solving. Prentice-Hall, Englewood

Cliffs, NJ. Norman, D.A., 1986. Cognitive engineering. In: Norman, D., Draper, S. (Eds.), User Centered System Design. Lawrence Erlbaum Associates, Hillsdale, NJ, pp. 31–62.

Payne, S.J., 1991. Display-based action at the user interface. International Journal of Man-Machine Studies 35, 275–289.

Rasmussen, J., Vicente, K., 1989. Coping with human errors through system design: implications for ecological interface design. International Journal of ManMachine Studies 31, 517–534.

Rogalski, J., Samurcay, R., 1993. Analysing communication in complex distributed decision-making. Ergonomics 36 (11), 1329–1343.

Samurcay, R., Rogalski, J., 1991. A Method for Tactical Reasoning (MTR) in emergency management: analysis of individual acquisition and collective implementation. In: Rasmussen, J., Brehmer, B., Leplat, J. (Eds.), Distributed Decision Making: Cognitive Models for Co-operative Work. John Wiley & Sons, Chichester, pp. 287–298.

Shepherd, A., 1989. Analysis and training in information technology tasks. In: Diaper, D. (Ed.), Task Analysis for Human Computer Interaction. Ellis-Horwood, Chichester.

Smith, M.W., Hill, B., Long, J.B., Whitefield, A.D., 1992. Modelling the relationship between planning, control, perception and execution behaviours in interactive worksystems. In: Diaper, D., Harrison, M., Monk, A. (Eds.), People and Computers VII; Proceedings of HCI’92. Cambridge University Press, Cambridge.

Smith, M.W., Hill, B., Long, J.B., Whitefield, A.D., 1997. A design-oriented framework for modelling the planning and control of multiple task work in Secretarial Office Administration. Behaviour and Information Technology 16 (3), 161–183.

Suchman, L.A., 1987. Plans and Situated Actions. Cambridge University Press, Cambridge.

The National Health Service Ambulance Service, 1994. Ambulance Service Operational Arrangements for Civil Emergencies. Internal Ambulance Service document.

Vicente, K.J., 1990. A few implications of an ecological approach to human factors. Human Factors Society Bulletin 33 (11), 1–4.

Whitefield, A.D., 1990. Human computer interaction models and their roles in the design of interactive systems. In: Falzon, P. (Ed.), Cognitive Ergonomics: Understanding, Learning and Designing Human Computer Interaction. Academic Press, London, pp. 7–25.

Woods, D.D., Hollnagel, E., 1987. Mapping cognitive demands in complex problemsolving worlds. International Journal of Man-Machine Studies (26), 257–275.

Wright, P., Fields, B., Harrison, M., 2000. Analysing human computer interaction as distributed cognition: the resources model. International Journal of Human Computer Interaction 15, 1–41.

Young, R., Simon, T., 1987. Planning in the context of human–computer interaction. In: Diaper, D., Winder, R. (Eds.), People and Computers III; Proceedings of HCI’87. Cambridge University Press, Cambridge, pp. 363–370.