It's very easy to come up with bad examples of visual information presented at meetings. (I've been keeping a file for years.) But the most notorious example (I think) is called "History of O-Ring Damage in Field Joints," and it was presented to management of Morton Thiokol and NASA in the days leading up to the Challenger accident in 1986. I worked for NASA for twelve years, and I still can't interpret this diagram!

Check it out for yourself.

The lessons we learn from uninterpretable information are as follows:

1. Plot data as a function of what really matters. In the Challenger case, the engineers plotted o-ring data as a function of time, on a launch-by-launch basis. Well, the problems with the o-rings were not time-variant. They were a function of temperature, and given that prior to the accident no Shuttle launch took place at a temperature below 51F, if you plot o-ring damage as a function of temperature the risk to that particular launch becomes chillingly (pardon the expression) clear.

You have to give your hearers a context for cause and effect. If they can't see that context in your visual display, they probably won't hear you when you tell 'em.

2. White space is your friend. The Thiokol engineers cluttered their information up with little rockets. Tufte calls that "chartjunk." Justly so, because it obscures the info content of the viewgraph while offering no new info in return. I look for a high "info/ink ratio."

Sometimes we engineers look at the Thiokol guys as being so moral, so ethical, because they attempted to blow the whistle on the o-rings before the accident. But the other side of the story is that the Thiokol guys obscured the facts so badly in their visual content that it was difficult for managers (who tend to have a short and shallow attention span) to align the visual and verbal messages before them.

But we can be quick to judge others in these cases. I know from experience that I'm subject to the same errors in judgment -- and I've yet to meet an engineer who isn't. Here are a couple of related chartjunk issues common to engineers:

• A series of six regression plots on one chart -- even the front row can't read the plot labels on the screen in this case. Put it in the handout instead and summarize it on the screen with a few critical numbers.
• A series of three curves on one regression plot -- if this were originally in color the individual traces might be discernable, but in black and white even a legend can't help the reader figure out which curve is which. Put it in the handout instead and summarize it on the screen with a few critical numbers.

3. Some things can't be presented on viewgraphs, and we shouldn't even try. Example: flowcharts. I admit that flowcharts may be going the way of the dinosaur in the age of object-oriented programming, but they can be used to...well, "chart flow" of other procedures besides programs. The problem is that if the flowchart contains more than a very few elements, the text within those elements is impossible to read if you're more than a few feet away.

   Here are two examples of material ready-at-hand but inappropriate for presentation:

   • A photograph of a test facility -- a good color photograph becomes a very poor black and white copy. Information communicated by nuances of color in the original is completely lost in the presentation. If you must use color photographs, display them in color and include color copies in your handouts. (Which is expensive.)
   • A chart of specifications -- the font will be too small to read; the text too much to absorb. This could have been included in a handout and not presented on the screen.

I come from a world where engineers take pages from books and make viewgraphs out of them, as if we can read the page as easily on the screen as in our laps. But the human eye can't process characters that are so small, so far away. And our brains won't let us. They tell us to think about something else, like sex, sports, music, movies, or beer. Anything else.