Human Factors Engineering Archives » Engineering for Humans

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

Posted by Benjamin Schwartz on 21 February 2022

CALLBACK is the monthly newsletter of NASA’s Aviation Safety Reporting System (ASRS)¹. 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 concerns². 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:

Human Factors Design Drives System Performance

Posted by Benjamin Schwartz on 28 March 2021

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.

Ergonomics

Posted by Benjamin Schwartz on 17 January 2021

The term ergonomics was coined by Wojciech Jastrzębowski in 1857 to mean “the science of work”¹ 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.

Human Factors Engineering (HFE)

Posted by Benjamin Schwartz on 17 January 2021

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:

System

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.”

User Experience (UX)

Posted by Benjamin Schwartz on 17 January 2021

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:

The Boeing 737 Max crashes represent a failure of systems engineering

Posted by Benjamin Schwartz on 14 May 2019

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 factors¹. 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.