I’m not sure if anyone reads the NY Times regularly, but a few days ago, they recently published an article about the most recent findings around the Boeing 737 Max crashes earlier this year.
In summary, many changes happened simultaneously and in near-isolation – the removal of backup sensors, the increase in scope, the decision to not require additional training, etc. Now, what we do on a daily basis doesn’t have the same immediate life-and-limb impacts of aircraft flight control design. Don’t the problems sound familiar, though?
https://www.nytimes.com/2019/06/01/business/boeing-737-max-crash.html
Not coincidentally, they published another article earlier in the year explaining WHY the 737 Max was such a challenge for Boeing to build and why it needed software intervention in the first place. In summary, the 737 is a VERY low-slung aircraft on the ground. Its short landing gear was designed for easier loading and unloading of passengers and cargo, as well as easier maintenance at smaller airports with less equipment. Many gains in jet engine efficiency have come from increasing the diameter of the first stage fan(s), which is a problem with limited ground clearance. Moving the engines forward and upward changes the center of balance and the center of thrust (both of which impact flight characteristics). Changing the way a plane flies can require extensive training if not full re-certification. To use a software metaphor, that’s not going from 1.0 to 1.1 – that’s going from 1.0 to 5.0.
A previous manager of mine always used the metaphor of trains. Companies are very good and building trains. PMs, developers, and designers are really good at making trains move forward in parallel. Some are fast, some are strong, some are beautiful. All too often, this is good enough. To run with the train metaphor our job is to not just build the trains, but to make sure they arrive safely. A passenger train needs to arrive at a station. It needs a platform where it can stop for several minutes to unload and load passengers. That station needs multiple platforms and switching so it can handle multiple trains. It needs signaling so trains know to stop outside the station. It needs to allow for the time and distance required for a train to actually respond to these signals. A freight train skips the station entirely. In short, it doesn’t matter how many wonderful trains you build if they crash into each other just outside the station.
As UX designers, we need to consider not just our products (the trains), but our users’ ingress and egress points. And we need to begin planning for failure – failure in our systems, and failure in our partner’s systems.
If you’re curious about designing for failure, consider reading Amber Case’s “Calm Technology.“