This is the seventeenth in a series of risk communication columns I have been asked to write for The Synergist, the journal of the American Industrial Hygiene Association. The columns appear both in the journal and on this web site. This one was substantially abridged for publication in the September 2008 issue of The Synergist, pp. 35–37. This is the longer original version.
You know a lot of complicated things about risk, health, safety, and the environment. Explaining what you know is a big piece of your job. But you can’t explain it all. So you’re going to have to simplify.
Simplification is complicated too – but even simplification can be simplified. Here’s a primer.
1. Recognize your reluctance to simplify.
There are lots of reasons why technical experts are sometimes reluctant to simplify. How many of these apply to you?
- You’re proud of what you know. It took a long time to learn, and now’s your chance to show off. You don’t actually want it to look easy.
- You’re afraid of being accused of inaccuracy. Simplifying means leaving stuff out. Your technical peers may see an incomplete explanation as an inaccurate explanation. It’s safer to say it all.
- You’re accustomed to complexifying instead. From primary school to professional school, the most complicated-sounding explanations usually get the best grades. No wonder you learned to make things sound complicated.
- You’re irritated at people intruding on your turf, which makes you want to be incomprehensible. At least sometimes, burying listeners in too much undigested information is a way of telling them to butt out.
Recognizing these motivations to keep things complicated will help you overrule them and resolve to simplify anyway.
2. Make the resolution: Better you than anybody else.
Whether or not you simplify what you tell people, what they learn will be simplified. The main question is who’s going to do the simplifying, you or your audience (or somebody in the middle – a journalist, for example).
So here’s your choice: Either you decide what to leave out, or your listeners “decide” what to ignore, misunderstand, or forget. You can tell them one-tenth of what you know and have them learn most of what you tell them, or you can tell them most of what you know and have them learn one-tenth of what you tell them. Keep the simplification in your own hands.
3. Figure out how simplified your message needs to be.
The main factor determining how much you need to simplify is how interested your audience is in what you’ve got to say. If you’re trying to alert people to a risk they find boring – which is probably the most common communication task of industrial hygienists – you’ll probably need to simplify your message down to a few quick bullet points. If people are worried about the risk, on the other hand, their attention span and their appetite for detail will be greater.
But even with a passionately interested audience, you’ll still need to simplify somewhat:
- There may not be much time. Especially in an emergency, you can’t afford to dawdle over data. And even routine communications have to stay within reasonable time constraints.
- People may be over-stressed. Too much anxiety can interfere with learning almost as much as apathy.
- People may be mistrustful. Listeners get irritated when they think you’re using the data to con them or bully them.
- Some information may just be too hard. Even with limited educations, people can master a surprising amount of complex detail when they’re motivated enough. But we all have our limits.
Based mostly on your audience’s motivation, and secondarily on factors like time, stress, trust, and education, figure out how much you need to simplify. Then stick to it.
4. Decide what you can’t afford to leave out.
First consider what your listeners need to know. Make a list of the key points (facts, skills, rules, whatever) it’s crucially important for them to master. Take the words “crucially important” to heart here. There’s a lot you’d ideally like people to know. But what do you actually need them to know?
Second, add information that will help people make sense of the things they need to know. If they need to know a particular safety procedure, for example, it will probably help to tell them why that’s the procedure – especially if some alternative looks easier and more sensible until you explain why it wouldn’t work. Or it may help to tell them what the penalties are for disobeying the procedure. What information to add at this stage is a judgment call. Add too little and your need-to-know message points will seem isolated and arbitrary. Add too much and your simplification effort will fail.
Third, spice up your message with additional information you think your listeners want to know. Remember, limited audience interest is largely why you need to simplify in the first place – so making your communication more interesting is a very good reason for making it longer and more complicated. So answer people’s questions, spoken and unspoken, even if you consider the questions a little off-point. And make time for anecdotes, examples, personal sidelights, and the like.
5. Be sure to include credibility-sensitive information.
By “credibility-sensitive information” I mean any information the absence of which will arouse your audience’s skepticism, now or later. Don’t ever “simplify out” information that has to stay in for the sake of credibility.
A good example is something your listeners already know that reflects badly on you, your employer, or your overall message: the spill you had a few years ago, the layoffs that may be coming soon, the ongoing debate with the union over safety regs, etc. Whatever “the elephant in the room” is – whatever people are mulling over as you speak, waiting to see if you’ll dare to mention it – mention it.
Even more important is information your listeners don’t already know that will cast doubt on your message if they learn it later. Suppose there are a dozen studies that suggest dimethylmeatloaf is pretty safe, and one that suggests it’s dangerous. When you discuss your company’s dimethylmeatloaf emissions, it’s fine to mention only a couple of the dozen studies on your side. But you absolutely must mention the one study on the other side. If you don’t, people who find out about that study later will rightly question your integrity. Simplification is not an excuse for misleading your audience.
6. Where you can, offer multiple layers of complexity.
Most technical reports have an executive summary with the bare bones, the body of the report with the whole story, and a bunch of technical appendices with endless peripheral details. That way readers can decide for themselves how deep to delve, how much complexity they want to master.
Nontechnical documents can have the same layered structure. So can websites. Oral presentations can’t, of course. But where possible, the best solution to the simplification dilemma is to offer people a choice between simplified and detailed versions of the same information.
7. Simplify your language.
Though language simplification matters less than content simplification, it still matters. Some pointers:
- Don’t use jargon to impress. If you can live without the word, cut it. If you absolutely need to use it, define it. Ideally you should introduce the concept first, talk about it for a while, then say there’s a technical term for this and introduce the term. Never start with the term.
- Simplify your nontechnical vocabulary too. Many people can’t understand past a 6th or 7th grade level, especially when they’re anxious. Even people who can understand words that are uncommon or long will learn more if you stick to more common, shorter synonyms.
- If you have a readability utility attached to your word-processing software, use it. (But not slavishly. You can’t discuss a trichloroethylene spill without mentioning trichloroethylene.)
- Be especially careful about words whose technical meanings are different from their common meanings – words like “significant” and “bias.” (See “Risk Words You Can’t Use” in the August 2005 issue.)
- Keep your sentence structure simple too. Aim for short sentences without a lot of subordinate clauses. Concrete nouns work better than abstract ones; active verbs work better than passive ones.
- Lean more on your verbs and less on your nouns. Suppose you’re talking about the problem of cracks in the effluent settling tanks. Compare these two sentences:
- “The cracks grow faster when there’s more effluent in the tanks.”
- “Tank crack growth rate is associated with effluent volume.”
8. Simplify your graphics.
Since I don’t often present technical data, I’m not especially knowledgeable about how to simplify graphics. And I’m not a visual person; I use far too few graphics myself.
But here’s what I’ve learned from watching others present technical data:
- Make one point per slide.
- Put the conclusion right on the slide. If it won’t fit, simplify the slide (or the conclusion) until it will.
- If you need to show people a complicated slide, build it piece-by-piece as they watch. Suppose you want to show them data on your emissions of five chemicals over three years. To emphasize how things are changing, show them Year 1 first, then Years 1 and 2, and only then all three. Or to emphasize which chemicals are the biggies, show them Chemical 1 first, then Chemicals 1 and 2, and so on till you’ve got all five on the slide.
- If possible, stick to bar graphs and pie charts. Without a tutorial, most people can’t make heads or tails out of a more complicated graphic like a scatter plot.
- Especially in tense situations, work with the image, not the projector (or computer). That is, don’t stand next to the equipment, glaring at your audience while it glares at the image. Instead, stand where you and the audience can ponder the image together, literally on the same side (of the screen).
9. Get help.
Ask a couple of nontechnical people to read through your draft or listen as you run through your presentation. Don’t just ask for overall feedback at the end; urge them to stop you whenever something is unclear. And urge them to stop you whenever they’re getting bored too. (We often experience information we’re having trouble understanding as “boring” rather than as too difficult.)
You can get help from your actual audience too. As you speak, watch for glazed eyes or wandering eyes. And watch for note-taking. People who are writing down nothing you say probably don’t understand; people who are frantically trying to write down everything you say surely don’t understand. If you suspect you may have lost them, try to find out – ask if they have any questions, or ask them a question or two. If it turns out you did lose them, apologize and back up – and ask them to tell you if you go off-track again.
10. Use signposts to keep your audience oriented.
When people don’t understand technical information, the problem isn’t always that the information is too complicated. Quite often the information isn’t signposted well enough. People get lost. They understand the individual words and sentences – but they have lost track of what you’re trying to accomplish or which point you’re up to now. They are literally disoriented.
Written documents have a lot of signposts to keep people oriented. Heads and subheads signify a major shift in focus; a new paragraph indicates a smaller shift in focus; even the period at the end of a sentence says we’re moving now from one thought to the next. Skilled writers learn to use these written signposts effectively.
There are fewer signposts when you’re speaking, so you need to make good use of the ones you’ve got. Topic sentences and transitional phrases are crucial. “We’ve been talking so far about X. Now I want to shift to a different aspect of the problem, Y.”
The better your signposting, the better your audience can follow complicated material – and so the less you’ll need to simplify.
One of the things to signpost is tough sledding ahead. “We’re coming to a part of my presentation that may sound awfully technical to some of you. But it’s fundamental to answering the questions you were asking earlier. Hang in there with me for the next few minutes, and then it will get simpler again.”
Copyright © 2008 by Peter M. Sandman
