The technicalities that ruin technical communication
Subscriber Benefit
As a subscriber you can listen to articles at work, in the car, or while you work out. Subscribe Now
Many organizations develop technical documents like white papers and blogs to explain the advantages they offer or to educate their stakeholders about situations or issues. And all too often, those efforts fall short of their objectives. Their target audiences come away not knowing any more and the organization’s team has essentially wasted the time they spent writing.
While there could be any number of causes (including the simple fact some people don’t write well), my experience points to several common reasons white papers and other technical communication tools often fail to connect with readers.
One of the most common reasons technical materials aren’t successful is because they’re written at the organization’s level of knowledge instead of the customer, prospect, or other stakeholder’s level. It’s what happens when we fail to recognize others may not know the same things we do. The phenomenon is so common it’s earned a name: the curse of knowledge.
I’m not saying knowledge is an inherently bad thing. Every society and organization needs smart people who have learned how to figure things out. If your appendix starts throbbing, you’d rather check in with a doctor than the accountant who lives two doors down. (But if you get a personal note from the IRS, you’d turn to the accountant without hesitation.)
The problem occurs when there’s an imbalance, such as when the person who is sharing the information has greater knowledge on that subject than the sharer’s target. Sometimes it’s an educational difference, but more often it’s a degree of awareness. If you’ve repaired a couple thousand hernias you regard them differently than your next patient will. When you talk with other docs, you use a lot of shorthand and abbreviations.
But as you explained the surgery to the patient, you threw in several of those abbreviations and used some of that shorthand. The patient nodded, since they didn’t want to appear to be stupid, but they understood very little of what you said. You’re frustrated because patients seem to ignore your advice. They’re frustrated because they don’t understand it, but are too intimidated to ask for clarification.
If your technical document’s writer is a highly trained graduate of one of Indiana’s many esteemed engineering programs, they might not realize the high school grad who worked into a supervisory role in the plant doesn’t share their deep background in metallurgy and physics. So when the readers encounter that common formula everyone in the engineer’s 200-level course had to memorize, two things happen. First, they get frustrated and embarrassed. Second, they stop reading because they assume they won’t understand any of it. If you want to connect, write at the reader’s level, not yours.
Every profession, industry, and company has its own argot — a unique language shared among those within the profession, industry, or company. Using that language is okay when communicating with peers, but when the audience is an outsider, it’s going to be confusing at best and indecipherable at worst. Save the jargon for your next meeting and keep it out of the materials aimed at those outsiders.
Another tendency among well-educated staffers who write technical communications like white papers is to express things with a great degree of complexity. As with jargon, that’s because they’re comfortable with that complexity. Often, though, readers are either overwhelmed, confused, or even repulsed by complexity, so they don’t come away with the desired message.
Once I had to share an automotive engineer’s explanation of a physics property known as rubber’s memory with auto mechanics. I could have provided long explanations of the effects at a cellular level, but chose instead to use a simple analogy. Stretch a rubber band as far as you can, and it snaps back to its original size and shape. That’s memory. And that’s an example you don’t have to be a physics major to understand.
One more issue? Technical communication materials are expected to share a substantial amount of information, but often they provide far too much. It isn’t that the extra information isn’t valuable; it’s that all the extra stuff dilutes the impact of the most important messages you hope to convey.
By scaling back the degree of detail, you allow your document to focus on those important messages. Instead of getting bogged down by every potential circumstance, the reader walks away from your technical communication with useful knowledge to help them make more confident decisions.
Scott Flood creates effective copy for companies and other organizations. His guide to evaluating freelance creative talent, The Smarter Strategy for Selecting Suppliers, can be downloaded at http://sfwriting.com.