Thursday, March 12, 2009

Red Flag Words

There's what you say. And there's how you choose to say it. When you're choosing how to describe something, you need to consider the effect your words will have on your audience. Some words, in particular, are what I call "red flag" words.

Don't use these words unless you want your audience - typically a customer - to panic. Of course, no one is asking you to lie, and in the right contexts these words are fine. In front of most customers, though, try to use words that convey the same meaning but in a softer way.

Why it's bad: Think car crashes, plane crashes.... crashes sound unrecoverable.
What to use instead: "Service interruption in which the software stopped"

Why it's bad: Poof! Magic? That kind of magic makes your product sound flaky.
What to use instead: "Not display" or "does not show up"

Why it's bad: AHHHHHH!!!!!! Even if you do usually mean a kernel panic.
What to use instead: "Issue with the underlying kernel" or "kernel ceases to process requests correctly"

Core dump
Why it's bad: It sounds like it left itself in pieces all over the floor, and it sounds like you can't recover.
What to use instead: "Take a snapshot of what the process is doing" or "diagnostic core" (hey, you're likely using the core for diagnosing what happened)

Why it's bad: If you can't explain it, how will you ever know what fixed it?
What to use instead: "Not fully understood" or "probably"

"I don't know"
Why it's bad: It sounds like you're giving up.
What to use instead: "We don't know yet, but here's what we're doing to find out." Give them some idea that lack of knowledge is hopefully a temporary state.

What words do you avoid around your more sensitive listeners? What phrasing do you use instead?

1 comment:

  1. That's a good start, Catherine.

    At my day job, systems which test poorly present the development team with an "opportunity for improvement". We also tend to avoid terms like "fast" and "took forever" because they are so sensitive to the context of the action being performed or the location of the person using the application.

    I must say, though that, especially when testing a system which is exhibiting anomalous behavior, but behavior of insufficient value to pursue, "I don't know" might be a better statement than a promise to "do more to find out" when you know that no more is going to be done unless the behavior repeats itself or worsens.