• Home
  • Category: Human Factors Engineering

You Don’t Understand Murphy’s Law: The Importance of Defensive Design

CALLBACK is the monthly newsletter of NASA’s Aviation Safety Reporting System (ASRS)1. Each edition features excerpts from real, first-person safety reports submitted to the system. Most of the reports come from pilots, many by air traffic controllers, and also the occasional maintainer, ground crew, or flight attendant. Human factors concerns feature heavily and the newsletters provide insight into current safety concerns2. ASRS gets five to nine thousand reports each month, so there’s plenty of content for the CALLBACK team to mine.

The February 2022 issue contained this report about swapped buttons:

A Confusing Communication Interface.
An Aviation Maintenance Technician (AMT) described this incorrect interface configuration noted by a B777 Captain. It had already generated multiple operational errors. 

The Captain reported that the Controller Pilot Data Link Communications (CPDLC) ACCEPT and REJECT buttons were switched.... This caused 2 occasions of erroneous reject responses being sent to ATC. On arrival, the switches were confirmed [to be] in the wrong place (Illustrated Parts Catalog (IPC) 31-10-51-02), and [they were] switched back (Standard Wiring Practices Manual (SWPM) 20-84-13) [to their correct locations].... These switches can be inadvertently transposed.

This reminded me of the story of Capt. Edward Aloysius Murphy Jr., the very individual for whom Murphy’s Law is named. It’s a great story, uncovered by documentarian Nick Spark whose work resulted in the key players receiving the 2003 Ig Nobel Prize3 in Engineering.

Murphy’s Law

You’ve probably heard Murphy’s Law stated as:

Anything that can go wrong, will go wrong.

That’s not incorrect, per se; in fact, it’s a useful generalization. The problem is that it is often misinterpreted. When something goes wrong, Murphy will be invoked with an air of inevitability: of course [whatever improbable event] would happen, it’s Murphy’s law!

You, dear reader and astute system thinker, may have already spotted the issue. If anything that can go wrong will, why not take steps to preclude (or at least mitigate the impact of (or at least be willing to accept)) this possibility?

The story of Murphy’s Law starts with some of the most important, foundational research in airplane and automotive crash safety. I will summarize the program, but there is no way I can do it justice. I’d highly recommend this article by Nick Spark, or the video below by YouTube sensation The History Guy.

Rocket sleds

Physician and US Air Force officer John Paul Stapp was a pioneer in researching the effects of acceleration and deceleration forces on humans. This work was done using a rocket-powered sled called the Gee Whiz4 at Edwards Air Force Base. A later version called Sonic Wind was even faster, capable of going Mach 1.75.

There’s a long history of doctors and scientists experimenting on themselves. Doctor Barry Marshall injected himself with the bacterium Helicobacter pylori in order to prove that ulcers were not caused by stress and could be treated with antibiotics, winning a Nobel prize for the work. Doctors Nicholas Senn and Jean-Louis-Marc Alibert each showed that cancer was not contagious by injecting or implanting it into themselves. Of course, self-experimentation is not without risk. Dr. William Stark died from scurvy while deliberately malnourishing himself to research the disease. Stapp was cut from the same cloth, subjecting himself to 29 rocket sled tests including some of the most severe and uncertain of the setups.

Human strapped into a chair atop a rocket sled on railroad tracks
The Gee Whiz with human subject.
NASA/Edwards AFB History Office, and pilfered from the Annals of Improbable Research

And they were quite severe. Test subjects routinely experienced forces up to 40g. The peak force experienced by a human during these tests was a momentary 82.6g, which is insane. By comparison, manned spacecraft experience 3-4g and fighter pilots about 9g. People lose consciousness during sustained forces of 4-14g, depending on training, fitness, and whether they’re wearing a g-suit.

Stapp and his fellow subjects suffered tunnel vision, disorientation, loss of consciousness, “red outs” due to burst capillaries in the eyes, and black eyes due to burst capillaries around the eyes. They lost teeth fillings, were bruised and concussed, they cracked ribs and broke collarbones. Twice Stapp’s wrist broke from a test and one of those times he simply set it himself before heading back to the office. The team, particularly project manager George Nichols, were legitimately worried about killing test subjects as they were accelerated faster than bullets and close to the speed of sound6.

Six frames of subject's face clearly in discomfort and experiencing high winds
Stapp during a test on Sonic Wind.
NASA/Edwards AFB History Office, and pilfered from someone posting it on Reddit

All of this effort was designed to understand the forces humans could withstand. It had been thought that humans were not capable of surviving more the 18g, so airplane seats weren’t designed to withstand any more than that. Stapp thought, correctly, that aviators were dying in crashes not because of the forces experienced but because their planes didn’t have the structural integrity to protect them. The work lead to major advances in survivability in military aviation.

Stapp then applied his expertise to automotive research, using the techniques he’d developed to create the first crash tests and crash test dummies. He also advocated for, tested, and helped to perfect automotive seatbelts, saving millions of lives. A non-profit association honors his legacy with an annual conference on car crash survivability. We all really owe a debt of gratitude to Dr. Stapp and this program.


So, where does Murphy fit into all of this? Well, during the program there was some question about the accuracy of the accelerometers being used to measure g-forces. Another Air Force officer, Edward Aloysius Murphy Jr. had developed strain transducers to provide this instrumentation for his own work with centrifuges. He was happy to provide these devices to the rocket sled program and he sent them down to Edwards Air Force Base with instructions for installing and using them.

Black and white yearbook photo of a man in military uniform
Murphy as a college student.
U.S. Military Academy, West Point

The gauges were installed, Stapp was strapped in, and the test conducted. The engineers eagerly pulled the data from the devices and found… nothing. Confused, the team called Murphy to ask for help and he flew out to Edwards AFB to see for himself. Upon investigation, he found that the transducers had each been meticulously installed backwards, resulting in recording no data. He blamed himself for not considering that possibility when writing the instructions and in frustration said:

If there’s more than one way to do a job, and one of those ways will end in disaster, then somebody will do it that way.

Stapp then popularized the phrase, stating in a press conference that “We do all of our work in consideration of Murphy’s Law… If anything can go wrong, it will. We force ourselves to think through all possible things that could go wrong before doing a test and act to counter them”. With human subjects in highly risky experiments, the team put the utmost care into the design of the system and the preparation of each test event. By assuming that anything that can go wrong will indeed eventually go wrong, the team would put in the effort to minimize the number of things that could go wrong and thus maximize safety.


Murphy’s Law isn’t about putting your fate in the hands of the universe, it’s about defensive7 and robust design. Reliability engineering and the technique of Failure Modes, Effects, and Criticality Analysis (FMECA) have their roots in this concept.

It’s why we have polarized outlets and safety interlocks. It’s why any critical component should only be able to be installed the correct way, because the ASRS database is filled with hundreds, if not thousands, of reports like the one from the top of this story of parts that fit correctly but are actually installed wrongly8.

I heavily relied on the work of Nick Sparks for this article. He tells the story much better than I in A History of Murphy’s Law, which one reviewer compares favorably to The Right Stuff.

How have you seen defensive design practiced? Has Murphy’s law impacted your engineering approach? Share your thoughts in the comments.

Human Factors Design Drives System Performance

Bottom Line Up Front:

  • Human performance is a major factor in overall system performance
  • Humans are increasingly the bottleneck for system performance
  • Human factors engineering design drives human performance and thus system performance

Why care about humans?

In many system development efforts, the focus is on the capabilities of the technology: How fast can the jet fly? How accurately can the rifle fire?

We can talk about the horsepower of the engines and the boring of the rifle until the cows come home, but without a human pressing the throttle or pulling the trigger, neither technology is doing anything. A major mistake many systems engineering efforts experience is neglecting the impact of the human on the performance of the system.

A great example is the FIM-92 Stinger Man Portable Air Defense System. Stinger had a requirement to hit the target 60% of the time, which was met easily in developmental testing. However, put in the hands of actual soldiers, it only hit the target 30% of the time. An Army report found that the system suffered from several shortcomings including poor usability and a lack of consideration for the capabilities of the intended user population. The technology hit the mark, but the system as a whole failed1.

Let’s illustrate with a more everyday example. I play ice hockey and use a professional composite stick. I would guess that my fastest slap shot clocks in at around 50 mph. A pro using the exact same stick could easily break 100 mph. Clearly the technology isn’t any different, I just don’t have the same level of skill. The performance is the combination of the technology and the human using it.

System performance = technology performance * human performance

Once we acknowledge that fact, it’s clear that we must understand the capabilities and limitations of the users to understand how the system is going to work in the real world. Most human factors models capture this interaction in one way or another. My preferred model for most systems is the FAA human factors interaction model, shown below. This model shows a continuous loop. The human takes in information through sensory capabilities, makes a decision, and translates that decision into actions to the system; then, the system takes those inputs, responds appropriately, and updates the displays for the loop to repeat.

This just drives home the point that system performance is driven by both technology and human performance. But, simply accounting for human performance is the bare minimum. In most cases we can go much further, designing the human-technology interactions to enhance the performance of the human and thus the integrated system.

The human bottleneck

A related model, often used by the military, is the OODA loop: Observe, Orient, Decide, Act. In any competition from ice hockey to strategy games to aerial dogfights, an entity that can execute the OODA loop faster and more accurately than their opponent, all other factors being equal, will win. This is a useful paradigm for exploring human performance in complex systems.

Systems developers have paid more and more attention to the OODA loop in recent decades, as computer technologies have significantly sped up the loop. We have more ability to collect and act upon information than ever before, to the point that it can be overwhelming if not managed effectively. We’ve come a long way from WWII cockpits with dial gauges and completely manual controls to point-and-click control of otherwise-autonomous aircraft. Computers used to require tedious manual programming with careful planning for even relatively simple tasks, and lots of waiting around for programs to finish running. Now, computers can complete tasks nearly instantaneously2 and are often idle waiting for the human’s next command. Automation has taken over many simpler tasks, and can do them better and more reliably than a human.

In short, it’s not the technology delaying the OODA loop; the human is the bottleneck.

The role of human factors engineering

Even selecting the very best humans and providing them with the very best training can only improve performance so much, and that’s a pretty costly approach. The solution is obvious: engineer superhumans. However, effective human factors engineering can support and enhance human performance.

Human factors engineering (HFE) is a broad and multidisciplinary field that addresses any interface between human and technology. Depending on the needs of the system, this could be as simple as ensuring that displays are clearly readable. For advanced systems with autonomous capabilities, HFE supports effective functional allocation among the technology and human elements of the system, maximizing the value of both; the technology handles the things that don’t require human decision making to allow the user to focus on the tasks that do require uniquely human capabilities. Effective human interfaces support the human’s tasks by presenting the right information at the right time in the most useful manner, allowing the human sensory and cognitive components to work speedily and accurately. That’s followed by intuitive controls for transmitting the human’s decision back to the technology.

The OODA loop is sped up when the human gets the right information presented in an effective and timely manner and can act on that information also in an effective and timely manner. When the human is the bottleneck, any HFE design improvements that support human performance have a direct corresponding impact on system performance. In order to have the biggest impact, the HFE effort must be initiated early on when those allocation and design decisions have not yet been made. Additionally, the human must be captured in all system architectural, behavioral, and simulation models.

The Stinger example demonstrates the risk of pushing off human factors engineering, and that was for a relatively straightforward system. To enhance the OODA loop and maintain a competitive edge in advanced modern systems, HFE is a must. System performance is the product of technology and human performance, and HFE is essential for ensuring the human aspect of that equation.


The term ergonomics was coined by Wojciech Jastrzębowski in 1857 to mean “the science of work”1 with the goal of improving productivity and profit. He described the importance of physical, emotional, entertainment, and rational aspects of the labor and employee experience, but the context was squarely on factory-type production.

Over time, this has evolved into two, slightly different definitions.

Workplace safety

In the United States, ergonomics is most often associated with equipment or workplace design. An “ergonomic” computer mouse is supposedly more comfortable and less likely to result in repetitive strain injury. The Occupational Health and Safety Administration (OSHA) and National Institute for Occupational Safety and Health (NIOSH) provide guidance for workplace design to reduce the risk of occupational injury.

This definition is a subset of human factors engineering (HFE) that may be also called occupational health and safety. It’s related to anthropometrics (the study of human body measurements) and industrial engineering.

Human factors engineering

Around the world, ergonomics is more often synonymous with HFE. The International Ergonomics Association provides this definition: “scientific discipline concerned with the understanding of interactions among humans and other elements of a system, and the profession that applies theory, principles, data, and methods to design in order to optimize human well-being and overall system performance”.


These different definitions of the same term came about by parallel evolution driven by broader demand for human engineering.

In the US, the term human factors engineering was coined to describe research into aviation human error during World War II. It began being applied to other industries and grew in scope to encompass a range of related fields. Some ergonomists began practicing HFE while ergonomics continued to focus on workplace impacts and fell under the umbrella of human factors.

The same demand existed for human engineering around the world for aviation and then computers, but the term HFE wasn’t in use. Instead, the application of ergonomics expanded to meet the need. This has lead to the different terms being used in different parts of the world.

Human Factors Engineering (HFE)

Human factors engineering (HFE) is a broad and multidisciplinary field that designs and evaluates the human interfaces of a system.

Don’t stop reading — that definition masks a lot of complexity. Let’s break it down:


INCOSE defines system as “an arrangement of parts or elements that together exhibit behaviour or meaning that the individual constituents do not. Systems can be either physical or conceptual, or a combination of both.”

Systems may include any combination of hardware, software, people, organizations, processes, information, facilities, services, tools, consumables, etc. A system can be as complex as the entire universe or as simple as two people interacting.

Human interfaces

When people hear “human interface”, they usually think software or hardware interfaces. But, interfaces really encompass any human interfaces with any of the other system components as defined above.

A great example is Crew Resource Management, which is a system for pilot interpersonal communication and shared decision making. No other system components are involved, just the humans in the cockpit1.

Think of a trip to the grocery store. You propel the cart, observe price tags and product packaging, smell the prepared foods, hear the muzak, talk to the butcher, handle products, place items on the checkstand conveyor belt, talk with the cashier, use the card reader to pay, check the accuracy of the receipt, etc. All of these are interfaces with some level of design. There’s a whole field of study on grocery store psychology.

Design and evaluate

What does it mean to design and evaluate an interface?

Obviously, it’s highly dependent on the requirements and context of the system. This is where relevant human factors expertise is required to understand the aims of the system and the interfaces to be designed, decompose those into human factors objectives, and specify how success will be evaluated.

It’s best to specify the verification method before designing, to ensure that you’re clear on the goal you’re working towards. Common metrics include user satisfaction, accuracy and error rate, speed, situation awareness, workload, usability, and engagement.

Broad and multidisciplinary

HFE covers a range of fields that may include: human-computer interaction, anthropometry, physiology, psychology, macroergonomics and organizational psychology, cognitive science, industrial design, user experience, and more.

Because HFE is such a broad field, it may take a team of experts with different specialties to effectively address the range of considerations applicable to any given system.


You should now have a better understanding of the full scope of what it means that HFE designs and evaluates the human interfaces of a system.

You may also be interested in the relationship between HFE and ergonomics and user experience (UX).

User Experience (UX)

The term user experience was coined in 1993 by Don Norman while working at Apple. He intended it to encompass a person’s entire experience related to a product, from any feelings they had prior to using it, to first seeing it in the store, getting it home, turning it on and learning how to use it, telling someone else about it, etc.

I highly recommend this short video where Mr. Norman explains this history and also complains about the frequent misuse of the word:

How does UX relate to human factors engineering?

Human factors is an umbrella term that covers a range of fields which design and evaluate the human interfaces of a system. We often think of a system as hardware and/or software, but it can also include social and organizational interfaces.

Thus, UX is very much a type of human factors. UX is distinguished from related specialties like human computer interaction (HCI) or interaction design by extending the scope of consideration beyond the product itself to any interface which might affect the user’s perceptions and feelings of the product. Yet, the goal is the same: understand the human’s needs in order to design interfaces that meet them1.

UX is very much a type of human factors.

Recently the field of customer experience (CX) has begun to emerge. CX focuses on whatever interactions a customer has with a business, which may be independent of a product user experience. CX and UX are the same basic concept, just with slightly varying scopes. CX emphasizes the design of the sales process and the customer as a user of that process. A product UX team may not consider the sales process if the “user” isn’t the same as the customer.

Why do we care about the user’s experience? For the same reason we care about all of the other functions of human factors. People seek out products and services to meet their needs. When we meet those needs better than the competition2, they’ll come back for more.

The Boeing 737 Max crashes represent a failure of systems engineering

The 737 is an excellent airplane with a long history of safe, efficient service. Boeing’s cockpit philosophy of direct pilot control and positive mechanical feedback represents excellent human factors1. In the latest generation, the 737 Max, Boeing added a new component to the flight control system which deviated from this philosophy, resulting in two fatal crashes. This is a case study in the failure of human factors engineering and systems engineering.

The 737 Max and MCAS

You’ve certainly heard of the 737 Max, the fatal crashes in October 2018 and March 2019, and the Maneuvering Characteristics Augmentation System (MCAS) which has been cited as the culprit. Even if you’re already familiar, I highly recommend these two thorough and fascinating articles:

  • Darryl Campbell at The Verge traces the market pressures and regulatory environment which led to the design of the Max, describes the cockpit activities leading up to each crash, and analyzes the information Boeing provided to pilots.
  • Gregory Travis at IEEE Spectrum provides a thorough analysis of the technical design failures from the perspective of a software engineer along with an appropriately glib analysis of the business and regulatory environment.

Typically I’d caution against armchair analysis of an aviation incident until the final crash investigation report is in. However, given the availability of information on the design of the 737 Max, I think the engineering failures are clear even as the crash investigations continue.

Hazard analysis

The most glaring, obvious, and completely inexplicable design choice was a lack of redundancy in the MCAS sensor inputs. Gregory Travis blames “inexperience, hubris, or lack of cultural understanding” on the part of the software team. That certainly seems to be the case, but it’s nowhere near the whole story.

There’s a team whose job it is to understand how the various aspects of the system work together: systems engineering2. One essential job of the systems engineer is to understand all of the possible interactions among system components, how they interact under various conditions, and what happens if any part (or combination of parts) fails. That last part is addressed by hazard analysis techniques such as failure modes, effects, and criticality analysis (FMECA).

The details of risk management may vary among organizations, but the general principles are the same: (1) Identify hazards, (2) categorize by severity and probability, (3) mitigate/control risk as much as practical and to an acceptable level, (4) monitor for any issues. These techniques give the engineering team confidence that the system will be reasonably safe.

FAA Safety Risk Management Process flowchart and Risk Categorization Matrix table
FAA Safety Risk Management Process and Risk Categorization Matrix from FAA Order 8040.4B, Safety Risk Management Policy.

On its own, the angle of attack (AoA) sensor is an important but not critical component. The pilots can fly the plane without it, though stall-protection, automatic trim, and autopilot functions won’t work normally, increasing pilot workload. The interaction between the sensor and flight control augmentation system, MCAS in the case of the Max, can be critical. If MCAS uses incorrect AoA information from a faulty sensor, it can push the nose down and cause the plane to lose altitude. If this happens, the pilots must be able to diagnose the situation and respond appropriately. Thus the probability of a crash caused by an AoA failure can be notionally figured as follows:

P(AoA sensor failure) × P(system unable to recognize failure) × P(system unable to adapt to failure) × P(pilots unable to diagnose failure) × P(pilots unable to disable MCAS) × P(pilots unable to safely fly without MCAS)

AoA sensors can fail, but that shouldn’t be much of an issue because the plane has at least two of them and it’s pretty easy for the computers to notice a mismatch between them and also with other sources of attitude data such as inertial navigation systems. Except, of course, that the MCAS didn’t bother to cross-check; the probability of the Max failing to recognize and adapt to a potential AoA sensor failure was 100%. You can see where I’m going with this: the AoA sensor is a single point of failure with a direct path through the MCAS to the flight controls. Single point of failure and flight controls in the same sentence ought to give any engineer chills.

The next link in our failure chain is the pilots and their ability to recognize, diagnose, and respond to the issue. This implies proper training, procedures, and understanding of the system. From the news coverage, it seems that pilots were not provided sufficient information on the existence of MCAS and how to respond to its failure. Systems and human factors engineers, armed with a hazard analysis, should have known about and addressed this potential contributing factor to reduce the overall risk.

Finally, there’s the ability of the pilots to disable and fly without MCAS. The Ethiopian Airlines crew correctly diagnosed and responded to the issue but the aerodynamic forces apparently prevented them from manually correcting it. The ability to override those forces, plus the time it takes to correct the flight path, should have been part of the FMECA analysis.

I have no specific knowledge of the hazard analyses performed on the 737 Max. Based on recent events, it seems that the risk of this type of failure was severely underestimated or went unaddressed. Either one is equally poor systems engineering.

Cockpit human factors

An inaccurate hazard analysis, though inexcusable, could be an oversight. Compounding that, Boeing made a clear design decision in the cockpit controls which is hard to defend.

In previous 737 models, pilots could quickly override automatic trim control by yanking back on the yoke, similar to disabling cruise control in a car by hitting the brake. This is great human factors and it fit right in with Boeing’s cockpit philosophy of ensuring that the human was always in ultimate control. This function was removed in the Max.

As both the Lion Air and Ethiopian Airlines crew experienced, the aerodynamic forces being fed into the yoke are too strong for the human pilots to overcome. When MCAS directs the nose to go down, the nose goes down. Rather than simply control the airplane, Max pilots first have to disable the automated systems. Comparisons to HAL are not unwarranted.

In summary

Boeing is developing a fix for MCAS. It will include redundancy in AoA sensor inputs, not activating MCAS if the sensors disagree, MCAS activating only once per high-angle indication (i.e. not continuously activating after the pilots have given contrary commands), and limiting the feedback forces into the control yoke so that they aren’t stronger than the pilots. This functionality should have been part of the system to begin with.

Along with these fixes, Boeing is likely3 also re-conducting a complete hazard analysis of MCAS and other flight control systems. Boeing and the FAA should not clear the type until the hazards are completely understood, controlled, quantified, and deemed acceptable.

Many news stories frame the 737 Max crashes in terms of the market and regulatory pressures which resulted in the design. While I don’t disagree, these are not an excuse for the systems engineering failures. The 737 Max is a valuable case study for engineers of all types in any industry, and for systems engineers in high-risk industries in particular.