In response to a call for blog topics, my buddy Bill suggested I address the need for technical writers to connect with their audience. Specifically, “I think a lot of technical writers lack the ability to inject humanity into their writing (you excepted). Maybe share how to write in a relatable way without being an automaton..” Part of the talk I’ll be giving in Huntsville next month includes the need for space communicators to focus on their audience, so I’ll take a look at this now. Thanks for the input, Bill!
Do You Have a Specific Audience in Mind?
Whenever I get a new assignment, one of my first questions is usually, “Who is my audience?” This is a key question for any technical communicator because the who will often dictate the what in your writing. For example, is the audience familiar with your content? Have they dealt with it before or is it completely new to them? What is their relationship to your content or your organization? What sort of education do they have? What sort(s) of communications on your topic are they likely to have?
If you’re writing for a new audience, especially, it’s usually a good idea to get some idea of their interests, their expectations, or their preferred method of communication. Would a memo work better or a public/verbal/graphical presentation? It’s worth taking a little time to review the sources of information your audience uses, what tone/vocabulary they use, or what assumptions they use when discussing certain topics. Which reminds me…
Don’t Make Too Many Assumptions
Regardless of your audience, it never hurts to include plain-language introductions and explanations for your content before diving into your specific topic. For example, when I used to write papers about the Ares I-X flight test, I would include a paragraph or two up front providing background on NASA’s mission to send people to the Moon, Mars, and beyond, the Constellation Program charged with that mission, and the Ares launch vehicles that was to launch the hardware. Those few sentences provide the context for the flight test to be discussed in the paper.
Spell out nomenclature
In addition to providing plain-language background, a key tool for orienting readers is to define or spell acronyms the first time they are used, if only for clarity. This is a particular pet peeve of mine. Yes, it’s entirely possible that your audience will know what the various parts of your content are, but that’s not guaranteed. There can be times when specific acronyms can have different meanings even within sub-disciplines of the same industry. For example, does LCC mean Launch Control Center or Life Cycle Cost? Yes, it might become clear if enough context is provided, but why not just spell it out up front and save your audience the aggravation?
Make benefits clear
Engineers love technology. That’s understandable: it’s their career goal to create it. However, it can be a great temptation for technology geeks to get so excited about their hardware/software and how it works that they leave out something that is often crucial to the reading audience: what can it do for them? Again, this need not be too extensive, but most technical documents benefit from a simple sentence or two in their introduction that explains who the end user of a technology is and how/why they will use it.
Write With an End in Mind
Lastly, while you’re ensuring that your audience understands your content, you also need to consider how you want them to react upon receiving the information. Do you want compliance (in the case of regulations, rules, etc.)? Do you want an emotional reaction (“Hooray! We won the proposal!”)? Do you want to persuade?
Your audience, their relationship to the content, and your ultimate aim(s) when delivering that content will determine your word choice and tone. Choose wisely!