This article gives advice on how to overcome challenges that technical communicators often encounter when writing to or for engineers.
Establish best practices
Knowing technical communication best practices, and being able to clearly articulate and justify them, is critical. As an example, a 2006 Aberdeen group report showed that involving a writer in a project in the planning stages results in the highest possible success rate for project documentation.
This is because when a technical communicator is involved early, they have the best possible grasp of project needs and goals, and can arrange the content in a way that helps to achieve those goals. Knowing that best practice, and the reasoning behind it, will help you get involved in client projects early, thus ensuring the best result for both you and them.
As with all forms of communication, conducting adequate audience and purpose analysis up front is the single biggest key to success. You must have your questions and process for discovering relevant details down pat. For example, you might be told that you are communicating with engineers. But will non-technical people also wind up using the content you produce? Do you need to take into account the needs and perspectives of administrative personnel, for example? You must be disciplined in going through your process of analysis.
Use advanced tools
The basics of good writing cut across industries and audiences. You need to balance the need for sufficiently technical content with the likely literacy level of your audience, be it engineers, support personnel, or others. Microsoft Word offers a handy tool for diagnosing the reading level of any sentence or document. You can use those statistics to justify a revamp of needlessly convoluted text, or to support your choice of clear wording in your content.
Engineers are often attached to particular conventions of communication, even if those conventions are not optimal. Of course, you shouldn’t try to shock an engineering audience in order to move them towards a better communication technique. But you should be ready to advocate for better methods of communication when the time comes.
For example, the assertion-evidence method of creating presentations is generally a more effective way to convey your ideas than the typical PowerPoint structure. You probably can’t convince the president of an engineering firm to switch to that method when preparing for a presentation at a major conference, at least not right away. But perhaps you can expose him to the benefits of the assertion-evidence method by using it in some of your internal presentations.
Many engineers tend to focus on features instead of benefits. You have to focus the writing on the important needs that the tool or technology meets, and include only the feature content that relates to those needs. Some engineers (though certainly not all) might explain the need as “they have a need for our product”, but that is too general a statement to be helpful.
In addition to the pitfall that is posed by a too-great focus on features, individual word choices can trip up engineering content. Lohfield Consulting provides a list of words that damage proposals. Many of the items in their list impact writing for engineering audiences, including:
- Crutch words: Saying “We understand your requirements” instead of proving HOW you understand their requirements.
- Boasting words: When you say the technology is best-in-class, what does that mean? It’s more effective to talk about the specific benefits of the tech.
- Redundant words: Some engineers may think that, for example, “in close proximity to” sounds smarter than “close to”. But that’s rarely the case.
- Needlessly long words: Many engineers have a tendency to write to sound smart, rather than to be as clear as possible. You’ll have to find a balance between pushing for clarity and respecting the engineers’ desire for safety through sounding smart.
- Slang: Using terminology accurately is critical when writing for engineering audiences. But are they throwing in unnecessarily complex terms? And are those terms really understood throughout the industry, or are they only really clear to employees of the company or project you’re writing for?
A comprehensive knowledge of terminology may be overrated, since even within a given industry segment, or within a single company, acronyms and other terms can mean very different things. Still, one must be prepared – don’t go into a meeting without trying to understand the key terms that engineers may use. And set aside time early on in the project to master terms. Even if terminology knowledge is sometimes overrated, it can be the difference between getting one’s foot in the door, and being left in the cold.
Deal with myths
I’ve dealt with some business owners who believe that their content doesn’t need to be clearly written, or even grammatically correct, since they are experts with the subject matter, and their expertise will overcome all issues in the writing. However, the reality is that writing errors and unclear content can completely obscure the message. Eventually, static in the content renders the communication worthless.
You may also have to overcome the myth that technical communication is just writing, or even proofreading. Between design, research, and testing, writing tends to be a minority of what a technical communicator does.
Do you have any advice on writing for engineering audiences? Let us know!