Case Study 1: The Challenger Disaster — How a Chart Could Have Saved Seven Lives

Introduction

On January 28, 1986, the Space Shuttle Challenger broke apart 73 seconds after launch, killing all seven crew members. The cause was a failure of the O-ring seals in the right solid rocket booster, which allowed hot gases to penetrate the joint between booster segments.

The O-ring failure was not a surprise — not entirely. Engineers at Morton Thiokol, the contractor that manufactured the solid rocket boosters, had been warning about O-ring erosion for over a year. The night before the launch, with temperatures forecast to drop to 31 degrees Fahrenheit (well below any previous launch temperature), Thiokol engineers argued strenuously against launching. They presented data showing that O-ring problems had occurred on previous flights in cold weather.

NASA launched anyway.

The question that has haunted data visualization experts for four decades is: Could a different chart have changed the decision?

Edward Tufte, the Yale professor whose work on information design is among the most influential in the field, examined this question in detail in his 1997 book Visual Explanations. His analysis is one of the most famous case studies in the history of data visualization — and it carries lessons that extend far beyond engineering into every domain where data informs high-stakes decisions.

The Data That Was Available

The night before the launch, Morton Thiokol engineers faxed 13 charts to NASA. These charts contained data on O-ring performance across previous shuttle flights. The data was real, the concern was genuine, and the engineers were right.

But the charts failed.

Here is what the data showed, reconstructed from the Rogers Commission investigation:

The Damage Index is a composite measure of O-ring erosion and blow-by (hot gas passing the seal). Higher numbers indicate more serious damage. The forecast temperature for the Challenger launch (STS-51-L) was 31 degrees Fahrenheit.

What the Engineers Showed

The Thiokol engineers' 13 charts made several critical visualization errors:

Error 1: They only showed flights with O-ring damage. Of the 17 flights with temperature data, the engineers' charts included only the 7 flights where damage occurred. The 10 flights with no damage were omitted. This was a catastrophic filtering decision, because those undamaged flights provided crucial evidence: most of them occurred at higher temperatures. By excluding them, the engineers removed the very data that would have made the temperature-damage relationship unmistakable.

Error 2: They did not plot temperature against damage. The data was presented in a rocket-by-rocket format — each flight got its own mini-diagram showing which O-ring segments were affected. This made it nearly impossible to see the pattern across flights. Temperature was listed as a number alongside each diagram, but it was not used as an axis variable.

Error 3: The charts were cluttered and hard to parse. Each page contained technical drawings, annotations, and multiple data representations. The signal was buried in noise. Under time pressure (the teleconference was late at night before an early morning launch), decision-makers could not extract the critical insight.

Error 4: There was no clear "bottom line" statement. The charts documented O-ring problems without explicitly stating the conclusion that the data supported: O-ring damage increases dramatically at low temperatures, and a 31-degree launch would be far outside the range of any previous experience.

The Chart That Should Have Been Made

Tufte argued that one simple scatter plot — temperature on the x-axis, damage on the y-axis, all 17 flights plotted — would have made the case irrefutable.

Here is what that chart would look like in Python:

import matplotlib.pyplot as plt
import numpy as np

# Data from the Rogers Commission report
flights = {
    'temp': [70, 67, 57, 63, 70, 78, 67, 53, 67, 75, 70, 81, 76, 79, 75, 76, 58],
    'damage': [4, 0, 4, 2, 4, 0, 0, 11, 0, 0, 4, 0, 0, 0, 4, 0, 4]
}

fig, ax = plt.subplots(figsize=(10, 6))

# Plot all flights
ax.scatter(flights['temp'], flights['damage'], s=100, color='steelblue',
           edgecolors='navy', zorder=5)

# Highlight the danger zone
ax.axvline(x=31, color='red', linestyle='--', linewidth=2,
           label='Forecast launch temp: 31°F')
ax.axvspan(20, 53, alpha=0.1, color='red', label='Below all previous launches')

# Annotate the coldest previous launch
ax.annotate('Coldest previous launch\n(51-C, 53°F, Damage: 11)',
            xy=(53, 11), xytext=(60, 12),
            arrowprops=dict(arrowstyle='->', color='darkred'),
            fontsize=10, color='darkred')

ax.set_title('O-Ring Damage vs. Launch Temperature\n'
             'All 17 Previous Shuttle Flights',
             fontsize=14, fontweight='bold')
ax.set_xlabel('Launch Temperature (°F)', fontsize=12)
ax.set_ylabel('O-Ring Damage Index', fontsize=12)
ax.legend(loc='upper right', fontsize=10)

ax.spines['top'].set_visible(False)
ax.spines['right'].set_visible(False)
ax.set_xlim(25, 85)

plt.tight_layout()
plt.show()

What you would see: A scatter plot with a striking pattern. At temperatures above 65 degrees, most flights show zero damage (the cluster of points along the x-axis). Below 65 degrees, every single flight shows damage, and the coldest launch (53 degrees) produced the highest damage index (11). A red dashed line at 31 degrees — the forecast launch temperature — sits far to the left of any data point, in uncharted territory. The visual message is immediate and visceral: launching at 31 degrees would be an extrapolation into the unknown, at a temperature where the trend line predicts catastrophic damage.

This is the chart that could have saved seven lives.

Why the Chart Wasn't Made

The failure was not one of intelligence or intention. The Thiokol engineers knew the data. They felt the danger. They argued against launching. The failure was one of visualization and communication — the inability to present data in a form that made the correct conclusion unavoidable.

Several factors contributed:

1. Expert blindness. The engineers understood the relationship between temperature and O-ring performance so deeply that they assumed others would see it too. They presented the raw data expecting the audience to connect the dots. But NASA managers, under schedule pressure and political expectations, needed the dots connected for them.

2. Confirmation bias in the audience. NASA managers wanted to launch. The default decision was "go." To override that default required not just data, but compelling data — a visualization so clear that ignoring it would feel like ignoring a fire alarm. The engineers' cluttered charts did not reach that threshold.

3. Organizational dynamics. The teleconference structure placed the burden of proof on the engineers arguing against launch, rather than on those arguing for it. In risk management terms, the null hypothesis was "safe to launch" — exactly backwards from what safety culture demands.

4. Time pressure. The teleconference happened late at night. Charts were faxed (this was 1986). There was no time to iterate on the visualization, to try different approaches, to step back and ask: "Is this chart making the argument as strongly as the data warrants?"

Lessons for Business

The Challenger case is extreme — the stakes were human lives. But the underlying failure pattern repeats every day in business, with consequences measured in dollars rather than lives:

Lesson 1: Include All the Data

The engineers' decision to show only flights with damage was well-intentioned — they wanted to focus attention on the problem. But by omitting the "no damage" flights, they removed the contrast that would have made the pattern visible. In business EDA, this manifests as cherry-picking: showing the quarters that support your argument, the customer segments that prove your point, the metrics that look favorable. Always show the full picture. If the pattern is real, it will be stronger with all the data, not weaker.

Lesson 2: Let the Axes Do the Work

The most powerful analytical tool in the visualization toolkit is the scatter plot: put the variable you think is the cause on the x-axis, the variable you think is the effect on the y-axis, and look. The Thiokol engineers had the data for this plot. They chose instead to present it in a format that did not use temperature as an axis. In business, this is equivalent to presenting revenue data in a table when a line chart would show the trend instantly. The choice of axes is the choice of argument.

Lesson 3: Design for the Decision-Maker, Not the Analyst

The engineers understood their own charts. The NASA managers did not. In business, the equivalent is a data scientist presenting a confusion matrix to a CMO or a SHAP plot to a board of directors. The audience determines the design. If the decision-maker can't absorb the insight in 10 seconds, the visualization has failed — regardless of how technically correct it is.

Lesson 4: The Default Matters

The organizational structure placed the burden of proof on those opposing the launch. In data-driven organizations, it's worth asking: where is the burden of proof in your decision-making process? If the default is "proceed as planned," then data that suggests caution must be overwhelmingly clear. If the default is "pause until convinced," then the bar is lower. The Challenger case argues for the latter default in any situation with high downside risk.

Lesson 5: One Chart, One Message

Tufte's proposed scatter plot makes exactly one argument: O-ring damage increases at low temperatures, and 31 degrees is dangerously far from any prior experience. It does not try to also explain the engineering mechanism, show the affected segments, or present the historical timeline. One chart, one message. In business presentations, the most common visualization failure is trying to make a single chart do too much.

The Legacy

In the years since the Challenger disaster, Tufte's analysis has become required reading in data science programs, engineering schools, and business analytics courses worldwide. It is arguably the single most influential example of how data visualization can be a matter of life and death — and by extension, of how it can be a matter of strategic success and failure.

The lesson is not that better charts would have guaranteed a different outcome. Organizational pressures, political incentives, and schedule demands were powerful forces. But better charts would have made it harder to make the wrong decision. They would have shifted the burden of proof. They would have forced anyone who wanted to launch to explicitly explain why a 31-degree data point in the red zone was acceptable.

That is what good EDA does. It doesn't make decisions. It makes the right decision harder to avoid.

Discussion Questions

1. Data filtering: The engineers showed only flights with O-ring damage, omitting undamaged flights. Can you think of a business scenario where similar data filtering (showing only "interesting" cases) would lead to a misleading conclusion?

2. Burden of proof: In the Challenger decision, the burden was on engineers to prove it was unsafe to launch, rather than on NASA to prove it was safe. How does your organization handle the burden of proof in data-driven decisions? Should data teams default to "proceed" or "pause"?

3. Audience design: Imagine you are presenting the O-ring data to three different audiences: (a) fellow engineers, (b) NASA program managers, (c) the U.S. Congress. How would your visualization differ for each?

4. Time pressure: The teleconference happened late at night with limited time. How can organizations build processes that protect data analysis from time pressure — ensuring that critical visualizations are clear before they're needed?

5. Modern parallels: Can you identify a modern example (in business, medicine, policy, or technology) where poor data visualization contributed to a bad decision? What chart should have been made instead?

6. The EDA connection: Reframe the Challenger data as an EDA problem. If you had been given this dataset with no context and asked to "explore it," what EDA steps (from Section 5.1 of this chapter) would have surfaced the temperature-damage relationship? Would the EDAReport class have caught it?

7. Ethical responsibility: Tufte argues that the engineers had an obligation to present the data more effectively. Is the obligation to communicate clearly a moral responsibility for data professionals, or merely a professional best practice? Where is the line?