Cognitive systems engineering

Cognitive systems engineering (CSE) is a design-oriented field that treats a person and the technology the person works with as one joint cognitive system, and studies how that system copes with real, complex work such as flying an aircraft, running a plant or operating on a patient (Wikipedia contributors, 2026b). Woods and Sarter, for example, treat cockpit automation problems as symptoms of deeper patterns in human-machine cooperation and aim to make automation a team player (Woods & Sarter, 1998). Its main disputes concern whether its methods, notably cognitive work analysis, are shown to improve designs, and whether its concepts, such as situation awareness, can explain or merely describe failures.

History

CSE was formulated in the early 1980s, out of human factors and cognitive science. It responded to three pressures: the growing complexity of computerised systems, accidents such as Three Mile Island, and the limits of the then dominant view of people as information processors (Baxter, 2011). The term is attributed to Hollnagel and Woods (1983). They chose new wording even though Norman had already introduced “cognitive engineering”, because they wanted to shift the focus from human-computer interaction to joint cognitive systems (Wikipedia contributors, 2026b). Woods (1985) framed design as the building of a joint human-machine cognitive system and named design hazards such as machine control of the interaction and a double-bind between responsibility and authority (Woods, 1985).

Alongside this line, Rasmussen and Vicente proposed in 1988 ecological interface design, a framework built on the skills, rules and knowledge levels of cognitive control (Rasmussen & Vicente, 1988). Bainbridge’s 1983 paper on the ironies of automation analysed what automation leaves the human to do (Bainbridge, 1983). Later work extended the field to resilience: a 2006 book treated failure as the result of the adaptations people make to cope with real-world complexity and success as anticipating the changing shape of risk (Hollnagel et al., 2006).

Core concepts

Joint cognitive systems and the functional approach

The joint cognitive system (JCS) is the basic unit of analysis. It stresses co-agency of human and machine rather than interaction between separate entities (Baxter, 2011). Where its boundary falls depends on the purpose and focus of the analysis: a person alone is a cognitive system but not a JCS, while a person using an artefact, or two or more people, is (Baxter, 2011). CSE takes a functional approach, asking what the system does and why, in contrast to structural views of socio-technical systems (Baxter, 2011). It studies work in situ, copes with complexity, and treats anomaly response, coordination and cognitive artifacts as topics (Wikipedia contributors, 2026b).

Cognitive work analysis

Cognitive work analysis (CWA) is the field’s best-known analytic framework. It is laid out as five levels: work domain analysis, control task analysis, strategy analysis, social organisational analysis and worker competency analysis (Ashoori et al., 2014), a structure attributed to Vicente (1999) (Wikipedia contributors, 2026c). Each phase analyses a different kind of constraint. Work domain analysis reveals constraints at different levels of abstraction, and control task analysis the constraints on what needs to be done (Ashoori et al., 2014). Strategy analysis identifies the alternative ways of doing a task that different situations trigger, and in traditional CWA worker competency analysis uses the skills, rules and knowledge framework (Ashoori et al., 2014).

Work domain analysis builds an abstraction hierarchy of purposes, values, functions and physical objects (Wikipedia contributors, 2026c). A blog worked example uses a car: the functional purpose is getting you from one place to another, abstract functions include power transfer, generalized functions are generic building blocks, physical functions are how these are implemented, and physical form is the construction detail (Hochstein, 2022). In one application to decision support, analysts ran work domain analysis first and then control task analysis on a subset of the work functions, which is compatible with traditional systems engineering; the same source states that designing and adopting decision support systems in complex work domains is hard for practitioners at project onset and should proceed incrementally (Cognitive Engineering Center, 2021). Methods for eliciting expert knowledge about tasks, a related but separate tradition, are covered in Cognitive task analysis.

Ecological interface design

Ecological interface design (EID) is a framework for interfaces based on the three levels of cognitive control (skills, rules, knowledge) with prescriptive design principles (Rasmussen & Vicente, 1988). Its stated goal is to support all three levels without forcing control to a higher level than the task requires (Rasmussen & Vicente, 1988). A later chapter offers the abstraction and decomposition space for matching interface features to constraints of the work domain, and four strategies (mimic, state space, nested symmetries, metaphor) for making displayed information coherent (Flach et al., 1999). A related concept, visual momentum, is described as how well an interface supports moving between information-seeking activities; raising it requires attention to the couplings between screens, within screens and within a display (Bennett & Flach, 2012). For the general evidence on layout, hierarchy and display choices, see Evidence-based interface design.

Automation and its ironies

Bainbridge named two ironies of the designer who tries to eliminate the operator. Designer errors are a major source of problems, and the operator is left with the tasks the designer cannot think how to automate, an arbitrary collection with little support (Bainbridge, 1983). Several consequences follow:

• Manual skills deteriorate with disuse, so an operator who only monitors may be inexperienced at take-over, exactly when abnormal conditions need more skill (Bainbridge, 1983). Diagnostic skill and knowledge develop only through use and feedback, so classroom instruction alone is not enough (Bainbridge, 1983).
• Working knowledge of the current process state takes time to build, so a sudden take-over has to be done on minimal information (Bainbridge, 1983).
• Human monitoring for rare abnormalities is impossible for more than about half an hour, so alarms must do it (Bainbridge, 1983). Asking a human to monitor an automatic system that does the job better than the human is an impossible task, since the operator can judge its decisions only at a meta-level (Bainbridge, 1983).
• Automatic control can camouflage failure by controlling against changes in variables, so trends show only when they are beyond control (Bainbridge, 1983).
• The most successful automated systems, rarely needing manual intervention, may need the greatest investment in operator training (Bainbridge, 1983).

A 2012 review found that these ironies persist despite improved technology: the more we depend on technology, the more skilled, trained people are needed as a last line of defence (Baxter et al., 2012). Bainbridge also argued that allocating tasks by what humans and machines are each best at (the Fitts list) is not sufficient, because it ignores integration and how to keep the operator’s skills and motivation (Bainbridge, 1983).

Automation surprises and clumsy automation

Woods and Sarter define automation surprises as situations where crews are surprised by actions taken, or not taken, by the autoflight system, starting from a gap between what users think the automation is set up to do, is doing and will do (Woods & Sarter, 1998). They are most likely when three factors converge: automation acting on its own, gaps in users’ mental models, and weak feedback about the agent’s activities (Woods & Sarter, 1998). Pilots usually detect the mismatch from unexpected aircraft behaviour, such as flying through a target altitude, rather than from displays of automation state, which may leave too little time to recover (Woods & Sarter, 1998). An earlier study of Airbus A-320 pilots reported lack of mode awareness as a major problem in pilot-automation interaction (Sarter & Woods, 1997).

Clumsy automation is automation whose burdens of use fall at the times the practitioner can least afford them (Woods & Sarter, 1998). An observation study of new technology in heart-surgery operating rooms found that clumsy automation constrains users, who tailor both the system and their tasks; studying that tailoring can expose hidden cognitive patterns useful for design (Cook et al., 1991). The authors argued that automation can add workload at peak times and that smooth change requires detailed understanding of users’ cognitive tasks (Cook et al., 1991). A “going sour” accident starts with a minor, recoverable event that the human-automation team manages into a hazard, and hindsight reviewers then say all the data was available (Woods & Sarter, 1998). Silent compensation by automation is a coordination breakdown: the crew stays unaware until the automation reaches its limits, causing a bumpy transfer of control, where a good human team partner would comment on the rising effort (Woods & Sarter, 1998).

Design responses

From these patterns CSE derives design requirements rather than a scored checklist. Observability is defined as the cognitive work needed to extract meaning from data, which differs from mere availability of data; a display passes the test if it helps practitioners notice more than what they were looking for (Woods & Sarter, 1998). The authors call flight mode annunciations a display with very low observability and recommend feedback that is transition-oriented, future-oriented and pattern-based, for example a vertical profile display like the moving map for horizontal navigation (Woods & Sarter, 1998). They warn against fixing feedback piecemeal with an indication or alarm per case, because more data is not effective feedback, and misdesigned feedback can talk too much, too soon or too little, too late (Woods & Sarter, 1998). Visibility is only half the fix: users also need to direct the automation as a resource, otherwise they can only take over manually (Woods & Sarter, 1998). Christoffersen and Woods name observability and directability as the two characteristics to design into automation from the start (Christoffersen & Woods, 2002).

Klein and colleagues list ten challenges for automation as a team player: the basic compact, adequate models, predictability, directability, revealing status and intentions, interpreting signals, goal negotiation, collaboration, attention management and cost control (Klein et al., 2004). They offer them as a blueprint for designing and evaluating intelligent systems (Klein et al., 2004), and they can serve as design review questions. Further recommendations from Woods and Sarter are to tolerate errors, avoid excess operational complexity, evaluate technology changes for the errors they invite, and improve observability of state, activities and intentions (Woods & Sarter, 1998). They treat excess complexity (accumulated modes, features and options) as a systemic source of “human error”, name indirect mode changes as a major factor in breakdowns, and recommend mode simplification (Woods & Sarter, 1998).

For the operator’s side of the problem, Bainbridge’s responses are to give alarm assistance, though a proliferation of flashing red lights confuses rather than helps, and to keep skills alive through hands-on control or simulator practice, training general strategies rather than specific responses because unknown faults cannot be simulated (Bainbridge, 1983). She argued that a display ideal for normal conditions can camouflage the development of abnormal ones, that operators should not have to page between displays for information needed in one decision, and that automatic systems should fail obviously and decide in ways the operator can follow (Bainbridge, 1983). For very fast failures she judged reliable automatic response necessary whatever the cost (Bainbridge, 1983).

Alarm floods illustrate the feedback problem in process plants. ISA 18.2 defines a flood as 10 or more annunciated alarms in any 10-minute period per operator, and an incident review by EEMUA found operators frequently overloaded by floods in loss incidents (Beebe et al., 2012). EEMUA 191 recommends alarm-logic design responses such as first-out, conditional alarms, delays, hysteresis and consequence-based priority (VanCamp, 2016).

Resilience

Woods groups the uses of resilience into four concepts, including resilience as the opposite of brittleness (graceful extensibility) and as network architectures that sustain adaptation to future surprises (Woods, 2015). The book Resilience Engineering: Concepts and Precepts takes the adaptation view of failure and success described above (Hollnagel et al., 2006). An extension of cognitive work analysis proposed by Naikar and Elix aims to promote the capacity of socio-technical systems to adapt (Naikar & Elix, 2016).

Questions, controversies, and new developments

Case evidence: when interface and automation design fails

The field’s claims are illustrated by accident investigations. The NTSB’s probable cause for Asiana 214 (2013) lists, as a contributing factor, the complexity of the autothrottle and autopilot flight director, inadequately described in Boeing’s documentation and Asiana’s pilot training, which increased the likelihood of mode error (National Transportation Safety Board, 2014). Moving the thrust levers to idle put the autothrottle into HOLD, a mode in which it does not control airspeed, and none of the three pilots noticed the change (National Transportation Safety Board, 2014). In HOLD the autothrottle does not wake up to protect speed, unlike when it is disconnected, and in training the pilot flying had seen the wake-up and been astonished by it (National Transportation Safety Board, 2014). A certification debrief had already flagged this as an inconsistency in the automation’s behaviour from the pilot’s perspective (National Transportation Safety Board, 2014). A mode error is an action suited to a different mode than the one the system is in, and encyclopedic summaries recommend clear state indicators and alternatives to modes (Wikipedia contributors, 2026e).

Other cases show related patterns. On Air Inter 148, the autopilot display showed only the first two digits of a vertical speed setting, so 3,300 ft/min looked like a flight path angle entry, and Airbus changed the display to four digits (Wikipedia contributors, 2026a). A trade-press summary of the Air France 447 final report says a stall warning sounded for 54 seconds without the pilots referring to it, and that angle of attack is not displayed directly to pilots (AVweb Editorial Staff, 2012). In the Therac-25 radiation accidents, an operator pressed P after an unexplained “Malfunction 54”, the normal action, because the facility had no documentation explaining it (Leveson & Turner, 1993). Leveson and Turner judged the interface a side issue in these accidents, yet concluded that software engineers need interface-design training or human factors input and that usability can conflict with safety (Leveson & Turner, 1993).

Is the evidence base for CSE methods adequate?

Naikar and Elix argue that CWA as formulated does not necessarily support actors in adapting their structure, and that the two foundational CWA texts offer no formative approach to analysing work organisation and leave unclear how the designs of the different elements are integrated (Naikar & Elix, 2016). A survey of CWA practitioners found no standard way of using CWA outputs in design, and more than half wanted an additional method (Read et al., 2015).

Situation awareness

Situation awareness is the concept most often used alongside CSE to describe what operators lose in automation incidents. Endsley’s definition (1995) covers perception of elements in the environment, understanding of their meaning and prediction of their near-future status, in three levels (Wikipedia contributors, 2026f). Flach (1995) is cited as arguing that situation awareness is circular as an explanation (Wikipedia contributors, 2026f). Defenders reply that its measures are falsifiable by their usefulness in prediction (Parasuraman, Sheridan and Wickens, 2008) (Wikipedia contributors, 2026f).

Do ironies of automation still hold?

Baxter and colleagues report the ironies persisting thirty years later despite improved technology (Baxter et al., 2012). Allspaw, writing about software operations, restates two of them: automation leaves the operator the tasks the designer could not automate, and operators are ill-suited to monitor rare abnormal conditions (Allspaw, 2012).

Broader connections

CSE shares with Cognitive task analysis the aim of understanding expert work, and turns its results into requirements for decision support and displays; see Evidence-based interface design for measured effects of display choices. Its view of people as part of a larger system contrasts with the information-processing models in Human cognition. The vigilance limit Bainbridge describes relates to the sustained-attention findings in Attention. The coordination between operator and automation that the team-player challenges describe resembles the problem of building shared understanding in Common ground.

Further reading

• Bainbridge (1983), “Ironies of Automation”: the short founding analysis of what automation leaves the operator, with design responses (Bainbridge, 1983).
• Woods and Sarter (1998), the NASA report on automation surprises and going-sour accidents: a readable account of observability and directability (Woods & Sarter, 1998).
• Klein and colleagues (2004), “Ten Challenges for Making Automation a Team Player”: usable as a design review list (Klein et al., 2004).
• Baxter (2011), the handbook chapter: a concise introduction to joint cognitive systems and the functional approach (Baxter, 2011).
• Naikar and Elix (2016): an open-access critique and extension of cognitive work analysis (Naikar & Elix, 2016).