All of us website builders and owners are lucky. What we do rarely, if ever, has life-threatening consequences. But of course we can all learn from other occupations, some of which have incredibly high stakes. Recently when listening to an episode of the podcast 99% Invisible, ((99% Invisible (or “99PI”) is one of my favorite podcasts. It’s about “design,” though in the broadest sense possible. Some of the most memorable episodes are about a failed Teddy Roosevelt-inspired stuffed possum, a World War II “deception unit”, the history of the hashtag character (technically, it’s called an “octothorpe”), and those hilarious thrashing blowup dolls you see at used car lots.)) I took away one such lesson.

The first episode of the two-episode series recounted the Air France 447 crash and how a lack of understanding the automated airplane controls likely caused the crash. While not the focus of the episodes, ((The series discusses the “Automation Paradox:” As we replace technical, challenging tasks with computers, robots, and easy-to-use interfaces, we save ourselves time and energy but become further removed from the underlying skills and systems. While not the subject of this post, the “automation paradox” is a very useful lens through which to view content management systems and the evolution of website-building tools. Every website I build places an abstracted interface between my clients and the database and code that actually output the website. This is makes it possible for people to manage their own websites but creates challenges when a bug or limitation arises due to lower-level technical issues.)) what really struck me was the copilot’s “bug report” to the captain in the final minutes before this plane crashed. The episode implies that there was still time to save the plane, but the way in which the three pilots communicated made diagnosing the reasons for and preventing the crash much harder.

Here’s what happened: Due to a speed sensor icing over, the pilots had lost their speed reading and the airplane’s autopilot had switched modes, crucially giving the pilots greater control of the plane—of which they seemed unaware. For a still-not-understood reason, one of the copilots attempted to drastically increase the plane’s altitude—by pulling a particular control lever way too far back—leading to a “stall.” In a stall, the plane wing’s angle is so extreme that it fails to generate lift and an upward-tilting plane can lose altitude. Following these actions, the pilots became confused about the state of the plane, and the plane’s very loud and unambiguous stall warning system kicked in.

Here’s how 99PI described what ensued (from 8:49-9:19):

Roman Mars (99PI Host): The copilots began to ring frantically for the captain to come in to the cockpit. At one point, one of them says, “F$&%, where is he?” ((Note: I’m directly transcribing the podcast transcript here. I’ve viewed other versions of this transcript that differ from this, but communicate the same thing. The actual conversations occurred in French so are translated in various ways.))

Interviewee: “The airplane was shaking. All kinds of alarms were going off.”

Katie Mingle (99PI Producer): One minute and thirty-eight seconds after the episode started, the captain came into the cockpit and asked, “What’s going on here?”

RM: The copilots did not say, “We’re in a stall.” Instead, one of them said, quote, “We’ve completely lost control of the airplane, and we don’t understand anything. We’ve tried everything.”

That’s a terrible bug report and one we can all learn from for when we need any type of support, tech or otherwise. The copilots’ communication doesn’t differ all that much from one type of common support request I get:

• “The website is broken.”
• “The website isn’t working.”
• “I can’t make the website do X.”

Even when those statements are technically right—something is broken and the user knows how it should work—they don’t provide any information to the person being asked to help.

At times, this story is hard to listen to because the pilots may have had time to correct their error. (And had they done nothing from the start, they likely would have been fine.) When the captain entered the cockpit, there were some crucial and simple pieces of information the copilots could have provided:

• A sensor wasn’t working and so the speed reading was inconsistent.
• Both of them had drastically increased the planes incline and altitude.
• The plane’s autopilot was literally saying “Stall” over and over in the cockpit.

This story contains all the information that I always tell people to provide when reporting a bug:

• What are you trying to do? (Fly the plane despite the lack of air speed reading.)
• What actions did you take just before the problem occurred? (Pulled lever way back to increase altitude.)
• What did you expect to happen? (This is still unclear to this day. The pilot explaining his actions may have gone a long way toward figuring out the cause.)
• What actually happened? Are there any error messages? (The “stall” warning system is sounding. The altitude is decreasing.)

Notice how this doesn’t include any guesses at how to fix the issue or what might be wrong. The point of asking for help is to get a fresh perspective of a problem. Speculation and panic just interfere with the new person’s ability to take in the known information and diagnose the unknown problem and solution.

It’s hard to blame the pilots for panicking in such a situation, but that only emphasizes the importance of practicing calm and descriptive—not prescriptive—communication of problems.