Over the Threat-Level Rainbow

September 11, 2001 didn’t change everything, but it changed a lot. We got a big new federal agency, the Department of Homeland Security; and one of the first things it gave us (aside from qualms about a name that evoked rhetoric about “das Vaterland”) was a system of communicating “the threat level” using the rainbow.

Before I say anything more, a word to the communication professional who was given the job to develop a system for telling us about the terrorist threat level in a clear way:
I am certain that what you came up with was great to start with, and that people way up your chain of command - people with communication skills on a par with those of compost heaps - told you to say it their way. We'll never get to see how you rose to the challenge so masterfully, but we know what it's like to be edited by a committee of people who couldn't write their way out of a wet paper bag with properly sharpened pencils. This post is not about you, it's about them. You can show them this post if you think it will help.

The threat-level rainbow instantly became joke material.
Why?

There were a lot of reasons, and all of them provide lessons for technical communicators. To recap, here ‘s a link to a page with a graphical explanation of the system. This is on the Department of Homeland Security web site:
http://www.dhs.gov/files/programs/Copy_of_press_release_0046.shtm

Here's the text in the graphic:

• (Red section) SEVERE: Severe risk of terrorist attack
• (Orange section) HIGH: High risk of terrorist attack
• (Yellow section) ELEVATED: Significant risk of terrorist attack
• (Blue section) GUARDED: General risk of terrorist attack
• (Green section) LOW: Low risk of terrorist attack

I think this graphic probably sent 90% of technical communicators up in a tight spiral. We had a lot of fun trying to top each other in pointing out what was wrong with it, because that’s what we do. But now that the DHS has decided to retire the threat-level rainbow, let’s see what lessons we can take from it and apply to our own work.

What should we do better?

Accessibility.
The colors were only meaningful to people with full-color vision. Although around 90% of the sighted population has full-color vision, using colors as the main keywords excluded TENS OF MILLIONS of Americans.
Do it better: Color is great, but if your audience might include people who can’t perceive it accurately, don’t use it as the main way to make your point.

Expectations.
As kids, we learn that the color sequence in the rainbow is red, orange, yellow, green, blue, purple. When we see red – orange – yellow, we expect the next color to be green. The threat-level rainbow breaks our mental model: After yellow comes blue. So lots of people had trouble remembering what blue meant.
Do it better: Choose metaphors and symbols that are intuitively clear.

Metaphors that work.
The reason the threat-level rainbow goofs up green and blue is almost certainly that green means everything is OK, and that definition is not open to renegotiation. Rather than stopping and finding a visual metaphor that provided a meaningful sequence of five elements, they broke the metaphor after the third of five messages.
Do it better: Broken metaphors don’t help your audience. If your metaphor breaks at any point, find one that works better.

Intuitive scale.
Most people would recognize hot – warm – tepid – cool – cold as a five-point scale; but the keywords severe, high, elevated, guarded, and low don't form an obvious sequence. Low isn’t the opposite of severe, high isn’t the opposite of guarded.
Do it better: Don’t invent a scale; find one that expresses the continuum you’re talking about.

Appropriate scale.
The confusion about what the blue and green levels meant was moot, because the USA has never been at either level.
Do it better: This is akin to explaining “DANGER” notices in a manual that doesn’t have any. Don’t. Who has time to do work that won’t be used?

Tight editing.
Take another look at the list of threat levels. Why say “HIGH: High risk of terrorist attack” when you could say “HIGH risk of terrorist attack” instead? And what about “GUARDED: General risk of terrorist attack” – what does that even mean?
Do it better: Phrase things consistently, use as few words as you can get away with, and make each word convey your meaning precisely.

Warnings we can respond to.
Any time you’re at an airport in the USA, sooner or later you’ll hear an announcement that says the threat level is orange. George Orwell and Robert Anton Wilson would be proud: It’s an announcement calculated to make us tense up inside, but there’s never any advice about how to identify, evaluate, respond to, or prevent threats.
Do it better: If you’re going to warn people about a hazard, tell them how to stay safe.

We could delve into the implications of setting up a multi-level system to inform us of threats and then leaving the threat level unchanged for five years, but that’s outside the realm of technical communication.

Seven Habits of Highly Defective Technical Writers

If you want to be a Highly Defective Technical Writer, you need to learn industry worst practices. Here are seven to get you started.

1. People who read help are stupid. People who write help are smart. Don't ever forget that, and don't ever let your readers forget it.
   
   
2. Complexity of grammatical construction correlates in a positive manner with the perception of intelligence; thus it is advisable under all circumstances to endeavor to utilize sentence structures and locutions commensurate with the level of one's own education.
   
   
3. It is considered presumptuous to address readers as if they were present. Passive voice is preferred.
   
   
4. When documenting software that allows you to create, change, or delete something - your contact information, for example - write a separate topic for each task. It's far too confusing to provide instructions for more than one task in a single topic, or to write steps that involve choices (such as "If you need to add a new telephone number, click Add Number. If you need to change a number, edit it in the text box"). Remember, your readers are stupid.
   
   
5. Take every opportunity to continue selling your product. Remind users how attractive it is, how sleek its design and stylish its colors. Remind them how intuitive and easy it is to use.
   
   
6. People open the help when they are scared of making a mistake. When presenting a task, point out how easy it is. When you get to the step where people tend to go wrong, tell them it's really simple. People like to be reassured that they are smart enough to get it right. Remember, they're stupid.
   
   
7. Don't bother with teh spelling checker. It's for careless people who either can't type very well or are too ingorant to spell well. Your smarter than that.

When you've mastered these worst practices, you'll be well on the way to being a Highly Defective Technical Writer.

Check your work

Think back to grade school. Think back to math tests. Remember what the teacher said at the start of every exam? "Check your work." The teacher knew that although you may know the heck out of long division or fractions, it's still easy to make really dumb mistakes - and the dumber the mistake, the easier it is to make. Worse, the smarter students are more confident of their ability to do error-free work, so they're less likely to catch their own really dumb mistakes. Sad but true: In my fifth-grade class, the class brain misspelled his own name on an exam. The teacher docked him three points for it, so he scored 97%.

We don't magically get over this when we finish school. What was true in grade school is still true, and it's more complex in the workplace because we aren't just answerable to ourselves; we rely on other people to do their work accurately, too.

You should be able to trust your teammates, but we all make mistakes. You won't make any friends by compulsively checking everyone else's work - and you'll run out of time to do your own work if you try - but if your organization doesn't already have a formal mechanism in place, you can set an example by asking your teammates to check your own work. "Do you mind checking this section for accuracy? If you like, I'll check whatever you have ready while you're looking at my material."

A couple things seem to cause a lot of trouble in technical writing and marketing collateral: company URLs and email addresses. I have seen far too many tech-savvy businesses (including IT service providers and multinational telecoms companies) publish contact email addresses that did not exist on their mail servers. They instructed their customers to contact them via email addresses that returned error messages. How smart would that make your company look? Although the warranty card may have always included the email address support@yourcompany.com and the URL www.yourcompany.com/support, that doesn't necessarily mean they work.

Take a few seconds to see what happens when you follow that link. Take a few seconds to send a test message to that email address, with an explanation and request for reply. Check your work.

If you haven't anything good to say...

If you woke up one day, prepared yourself to face the world, and realized, "My goodness. I have nothing good to say," or worse, "My goodness, I have nothing at all to say," would you say it anyway? Or would you let your blog get one day more stale?

And if that day stretched to a week, or a month, and you found yourself thinking, "My goodness. I still have nothing (good) to say," would you grow alarmed? Would you fault yourself for being lazy and self-indulgent, and firmly compel yourself to manufacture something you could post? Or would you keep silence out of concern that every time you tried to write, you found yourself wasting the time of your readers?

We all know that if you start a blog, you should treat it as a commitment as firm as any job. You should keep it fresh, expound upon matters within your realm of expertise, keep the opinions and advice coming. Stay positive. Build that Brand You. Market yourself nonstop.

But what happens if you DO hit a wall?
You go crunch, silently.
My goodness. I have nothing to say.

Reclaiming the boxes

A good friend just called me out - and properly so - for neglecting my audience (well, he said my blog) for so long.
I'm sorry.
Forgive me, readers, for I have sinned. I did not meet your expectation that I'd say something from time to time. I committed the writing sin of letting the material get stale. I demonstrated poor work habits by failing to treat this blog as work. Mea culpa. This is one time when it would have served me better to do a very 20th century thing: compartmentalize all the messy bits of my life.

Remember compartmentalization? It was the notion that you could chop up your life into chunks and put aside the bits you didn't want to think about at any given time. Remember what a bad reputation it had? Such an unhealthy thing to do - denying parts of your experience, your personal narrative. We're so much more emotionally healthy if we throw away all those little boxes that we use to compartmentalize our lives. And a lot of people did that.

You can identify the people who threw away the boxes, and don't approve of compartmentalization. The extreme cases are the ones at the next table over in your favorite restaurant, Having Issues (maybe even breaking up) in public; the ones in the office who are always on the phone, talking to friends about other friends, doing that thing we call "homing from work".

My office is in my house now. I was once skilled at compartmentalizing the parts of my life that don't need to come to work with me, but changing the way I work is changing the way I handle the rest of my life, too. I think I've still got the mental boxes for compartmentalizing my life; they've just gotten a bit muddled up. I work at home; does this go in the work box or the home box? It's easy to get sloppy.

Some things happened recently in my personal life, and rather than risk having them spill into the professional side of my life, I stopped blogging for a while, on the theory that it's just my blog and I can take a break if I want to. That wasn't a good way to deal with things. Old-school compartmentalizing would have served me better.

You'd think that after living through a couple decades of radical changes in people's assumptions about how we work and why we work and what we do for a living, I'd be better at adapting - but this isn't a matter of learning anything new; it's a matter of going back to what was considered good business etiquette a generation ago. Clothing styles from the '70s are back; maybe it's time to give retro work habits another look, too.

No more peanut butter sandwich exercises, please

It seems as though any time I meet someone and the conversation turns to what each of us does for a living, as soon as I say "I'm a technical writer," my partner in conversation is seized with a desire to tell me about some technical writing exercise in high school or college. "The prof showed us a cheese slicer, the kind with a wire and an adjusting knob, and told us to write instructions for using it. We were supposed to write it for someone who had never seen one - like a Martian or something."

My daughter told me about the peanut butter sandwich "technical writing" exercise, made livelier when the teacher dipped her hand into the peanut butter because nobody had specified that a butter knife be used. My own brush with this kind of exercise involved describing an everyday object in exacting detail, as if making a mechanical drawing with words, and explaining what each part of it does.

All these "technical writing" exercises seem to bear that same requirement: Write it for an audience that has no idea what you're talking about. They are all entertaining exercises - if you are fond of useless precision and work for work's sake - but they have almost nothing to do with technical writing. Can we please stop inflicting this silliness on students?

Never in my career have I written instructions for installing and using a frabbetizer, and expected that the people reading those instructions would be completely ignorant of the appearance and purpose of a frabbetizer. The instructions are in the box with the frabbetizer, or the frabbetizer help is part of the frabbetizer download. One way or another, they've got the silly thing in front of them; nobody ever reads a manual on the bus. So I don't have to describe the frabbetizer, beyond pointing out where to connect things or find non-obvious controls. In most cases, they know what it's for already, or they wouldn't have bought it. To address the case of the guy who's mystified by the box that the receiving department just left on his desk, I'll write a paragraph at the beginning of the manual that briefly describes what the frabbetizer is for, and includes some magic feel-good words: "The Model 2500 frabbetizer is a powerful, compact, and cost-effective reputation-polishing device for small organizations. Its small footprint, attractive walnut case, and unsurpassed ease of use make the Model 2500 a popular choice in home offices and start-up businesses." OK, now you know what a frabbetizer is, if you didn't before.

Having ensured that the reader knows what a frabbetizer is, our next step is to talk about all its parts and explain what each of them does, right? Wrong. Nobody cares what the parts do. So we're not going to do that.

Our next step is to talk about what the reader can do, and how to do it. Here's how to switch on the power; here's how to log on; here's how to set up your account; here's how to polish your reputation using the frabbetizer. We are not ever going to get into the nuts-and-bolts details of exactly how the frabbetizer polishes reputations, because nobody cares. Correction: no customer cares. That's all that matters.

Of all the sins a technical writer can commit, there is no sin so great as boring the reader with useless information - and that's exactly what those classroom "technical writing" exercises do. So let's put a stop to it. Students would be better served if the exercise involved identifying the audience for whom they are writing, and writing to the appropriate level.