Human factors in accident analysis

Why this topic matters

After an accident, people often ask a very direct question: who made the mistake? That question can feel natural because the actions of operators, clinicians, drivers, pilots, maintainers or controllers are often the most visible part of the event. They are close to the outcome, so their decisions and actions are easy to see.

But visibility is not the same as explanation. A person’s action may be the point at which an accident became visible, but that action is usually shaped by many conditions: workload, time pressure, training, interface design, equipment availability, procedures, supervision, staffing, communication, organisational priorities and regulatory assumptions. A human factors approach helps us examine those conditions carefully.

This matters because weak explanations lead to weak recommendations. If an investigation ends with “the operator did not follow the procedure”, the recommendation is often more training, a reminder, or another instruction to comply. Sometimes that may be appropriate. Often, however, it misses the deeper question: why was the procedure difficult to follow, easy to misunderstand, poorly supported, impractical in the operational context, or in tension with other demands?

Human factors makes accident analysis more useful by shifting the focus from blame to learning. It asks how people were expected to perform, what made performance difficult, what supported successful recovery, and what should be redesigned so that safe performance becomes easier and more reliable.

What human factors means in accident analysis

Human factors is concerned with the fit between people and the systems in which they work. In accident analysis, this means looking at people’s capabilities and limitations, but also at the tasks they perform, the tools they use, the environments they work in, the teams they coordinate with and the organisations that shape their work.

A helpful way to think about this is: people, tasks, tools, environment and system.

Swipe horizontally to view full table.

This structure keeps the analysis practical. It prevents the investigation from becoming either too narrow, by focusing only on the last person involved, or too vague, by saying that “everything is connected” without showing which connections mattered.

Human error as a symptom, not a conclusion

The phrase “human error” is common in accident reports, but it is often too broad to be helpful. It may describe what appeared to happen, but it rarely explains why it happened. Saying that someone forgot, misjudged, omitted a step, selected the wrong option or continued with an unsafe plan should open further analysis, not close it.

For example, a missed checklist item might reflect attention capture, fatigue, interruption, poor checklist design, time pressure, weak team cross-checking or a normal workaround that had become accepted. A poor decision might reflect incomplete information, misleading feedback, ambiguous procedures, unclear authority, excessive workload or a situation that changed faster than the system could support.

This does not mean that individual responsibility never matters. It means that responsibility should be considered in context. Accident analysis should distinguish between deliberate reckless behaviour, routine workarounds, well-intended adaptations, knowledge gaps, poor design, supervisory conditions and organisational pressures. These are not the same, and they do not call for the same response.

HFACS: a useful framework, used carefully

The Human Factors Analysis and Classification System, usually known as HFACS, was originally developed in aviation to support a more structured analysis of human and organisational factors. It is based on the idea that accidents are rarely caused only by the final unsafe act. Instead, unsafe acts are often shaped by preconditions, supervision and organisational influences.

HFACS is helpful because it gives investigators a language for classifying different kinds of contributors. This is particularly useful when organisations need consistency across reports, want to analyse patterns across many events, or need to move beyond vague labels such as “pilot error”, “operator error” or “non-compliance”.

Swipe horizontally to view full table.

Used well, HFACS can help make less visible contributors easier to discuss. It can show that an unsafe act was not simply an individual lapse, but part of a wider pattern involving equipment design, supervision, resourcing or organisational decision-making.

Used poorly, HFACS can become a coding exercise. An analyst can assign labels without explaining how the factors interacted or why they mattered. The category “organisational influence” is not useful unless the report explains what the organisational influence was, how it shaped the event, and what should change.

HFACS is not the whole analysis

It is best treated as a way to organise and code evidence, not as a substitute for explaining how the event unfolded. HFACS is a classification framework. It is not, by itself, a complete theory of how an accident unfolded. It can help organise evidence, but it does not automatically reconstruct timing, control, feedback, trade-offs, adaptation or interactions across organisations.

This is why HFACS is often stronger when it is combined with other forms of analysis. A timeline can clarify what happened and when. Task analysis can show how work was expected to be performed. AcciMap can map contributory factors across system levels. STAMP and CAST can examine control structures, constraints, feedback and responsibility. FRAM can help explore how everyday performance variability and functional couplings contributed to the event.

Swipe horizontally to view full table.

The purpose is not to use every method on every event. The purpose is to choose the method that fits the question. A small incident may need a simple human factors review. A major accident involving several organisations may need a systems-based analysis. A near-miss where people recovered successfully may benefit from examining both vulnerability and resilience.

When HFACS and systems methods are used together

There has been growing interest in combining HFACS with systems-theoretic methods such as STAMP. This makes sense because the two approaches have different strengths. HFACS gives a structured taxonomy of human and organisational contributors. STAMP and CAST provide stronger language for controls, feedback, constraints and system-level interactions.

A combined approach can be useful when the investigation needs both classification and explanation. For example, HFACS may help identify that fatigue, task saturation, inadequate supervision and resource constraints were present. A STAMP or CAST analysis can then ask how control actions, feedback loops, responsibilities and organisational constraints allowed these conditions to persist.

However, hybrid methods should be used with care. Combining frameworks can make the analysis richer, but it can also make it heavier, harder to explain and more dependent on analyst expertise. The test is not whether the method looks sophisticated. The test is whether the analysis produces clearer learning and better-targeted recommendations.

A practical way to analyse human factors

A good human factors accident analysis usually follows a simple logic.

First, reconstruct the event before labelling it. Build a clear account of what happened, what information was available, what decisions were made, what actions were taken and what conditions changed over time. Avoid assigning HFACS codes or causal labels too early.

Second, examine performance in context. Ask what shaped people’s perception, understanding, communication, timing and action. Consider workload, fatigue, training, experience, interface design, environmental conditions, procedures, supervision and organisational pressures.

Third, distinguish different kinds of behaviour. A slip, a knowledge gap, a rule-based mistake, a workaround, a routine violation and a reckless act are different phenomena. They need different explanations and different interventions.

Fourth, look for normal work. Many accidents involve actions that made sense locally or had worked before. Understanding work-as-done helps explain why the behaviour was reasonable to those involved at the time, rather than only why it looks wrong after the outcome is known.

Fifth, link findings to recommendations. A finding should not sit alone. It should connect to a practical improvement, such as better interface design, clearer feedback, improved staffing, more realistic procedures, targeted training, stronger supervision, better escalation criteria or redesigned assurance processes.

Questions that help move beyond blame

These questions are useful when reviewing human factors in an event:

• What was the person or team trying to achieve at the time?
• What information was available, missing, delayed, ambiguous or misleading?
• What made the situation easy or difficult to detect, interpret and act on?
• What was normal practice, and how did this event differ from normal work?
• Were procedures realistic for the conditions in which they had to be used?
• Did tools, interfaces, alarms or automation support timely understanding and action?
• Were workload, fatigue, staffing or time pressure relevant?
• Were responsibilities, authority and escalation routes clear?
• What controls were expected to prevent, detect or recover the situation?
• What feedback did decision-makers receive, and was it timely enough?
• What would make the safe action easier next time?

These questions are intentionally practical. They help the analyst stay close to evidence while still exploring the wider system.

Common mistakes to avoid

Be careful when the analysis does these things

• Stops at “human error” without explaining the conditions that shaped it.
• Uses HFACS codes as labels, without evidence or supporting statements.
• Treats non-compliance as automatically irrational or careless.
• Assumes that more training is the answer before examining design, workload, feedback and resources.
• Ignores recovery and successful adaptation, even when people prevented a worse outcome.
• Produces recommendations that are not traceable to the findings.

Human factors analysis should make reports more explanatory, not just longer. The best findings are specific, evidence-based and actionable. They show not only what people did, but why the system made that behaviour possible or likely.

Limitations and cautions

No method removes the need for judgement. HFACS, AcciMap, CAST and FRAM all depend on the quality of evidence, the skill of the analyst and the boundary chosen for the investigation. A method can create an appearance of rigour while still producing a weak explanation if the evidence is thin or the categories are forced.

It is also important not to treat “systemic” as meaning that no one is accountable. A human factors approach does not remove accountability. It makes accountability better informed by asking what individuals, teams, managers, designers, regulators and organisations could reasonably know, control and influence.

Finally, accident analysis should be designed for learning. The report should help people understand the event, recognise similar vulnerabilities and act on the findings. If the analysis does not support practical change, it has not yet done enough.

Related publication(s)

• Kaya, G.K. (2021). A system safety approach to assessing risks in the sepsis treatment process. Applied Ergonomics. 94,103408. DOI: 10.1016/j.apergo.2021.103408.
• Kaya, G.K., Humphreys, M., Camelia, F. and Chatzimichailidou, M. (2025). Integrating causal analysis based on system theory with network modelling to enhance accident analysis. Ergonomics. 1-28. DOI: 10.1080/00140139.2025.2516060.
• Kaya, G.K., Stallard, R., St-Laurent, M., Li, W.-C. and Sujan, M. (2026). Exploring unstable approaches in aviation: utilising functional resonance analysis method. The Aeronautical Journal. 130(1345):917-943. DOI: 10.1017/aer.2025.10108.
• Losi, E., Kaya, G.K., Camelia, F., Chatzimichailidou, M., Slater, D.H., Patriarca, R. and Sujan, M. (under revision). Systemic safety analysis of complex socio-technical events: insights from applying CAST and FRAM. Reliability Engineering & System Safety. Publication details forthcoming.

Selected references

• Dong, C., Zhang, Y., Wang, Z., Liu, J. and Zhang, J. (2024). The hybrid systems method integrating STAMP and HFACS for the causal analysis of the road traffic accident. Ergonomics, 67(7), 971–994. DOI: 10.1080/00140139.2023.2270783.
• Harris, D. and Li, W.-C. (2011). An extension of the Human Factors Analysis and Classification System for use in open systems. Theoretical Issues in Ergonomics Science, 12(2), 108–128. DOI: 10.1080/14639220903536559.
• Hollnagel, E. (2012). FRAM: The Functional Resonance Analysis Method. Ashgate.
• Leveson, N.G. (2004). A new accident model for engineering safer systems. Safety Science, 42(4), 237–270.
• Leveson, N.G. (2011). Engineering a Safer World: Systems Thinking Applied to Safety. MIT Press.
• Rasmussen, J. (1997). Risk management in a dynamic society: a modelling problem. Safety Science, 27(2–3), 183–213.
• Reason, J. (1990). Human Error. Cambridge University Press.
• Reason, J. (1997). Managing the Risks of Organizational Accidents. Ashgate.
• Salmon, P.M., Cornelissen, M. and Trotter, M.J. (2012). Systems-based accident analysis methods: A comparison of Accimap, HFACS and STAMP. Safety Science, 50(4), 1158–1170. DOI: 10.1016/j.ssci.2011.11.009.
• Shappell, S.A. and Wiegmann, D.A. (2000). The Human Factors Analysis and Classification System- HFACS. DOT/FAA/AM-00/7. Federal Aviation Administration.
• Underwood, P. and Waterson, P. (2014). Systems thinking, the Swiss Cheese Model and accident analysis. Accident Analysis & Prevention, 68, 75–94. DOI: 10.1016/j.aap.2013.07.027

Back to all resources