Technical writing is an art that one must approach with caution. Among the biggest mistakes that technical writers do that diminishes the quality of their work is assuming reader experience.
Assumptions that are made in technical writing benefit the author as it gives the user document a starting point. However, incompatibilities involving your assumptions and the actual user experience cause trouble to the reader. Thus, it’s important to handle it appropriately when doing technical writing.
Some examples of assumptions made in technical writing
- An assumption about knowing how to use a computer mouse
Suppose it involves instructions about maneuvering around a specific computer software. You’re likely to focus the user documentation around the functions of that computer software without explaining basic mouse instructions. So in a way, you’re assuming that the reader already knows how to operate a computer mouse and use its functions (like dragging items).
- Knowledge about acronyms
For more complicated or advanced acronyms, anyone dabbling on technical writing would know to spell it out at least once in the document. For example, you wouldn’t use GUI straight up and instead, you’ll inform your reader that it stands for Graphical User Interface. However, there are some oversights when writers unabashedly use acronyms when doing technical writing because it’s so “common.” However, remember that what is common in one area may not be as widely-known in another. For instance, you might use AM and PM when describing time. But in places where the 24-hour clock is the norm, those acronyms are practically meaningless.
How to solve some problems involving assumptions when doing technical writing
Sample case no. 1: Unfamiliar words
In technical writing, you sometimes become so engrossed on explaining something that you tend to overlook misunderstandings caused by unfamiliar words. For example, when discussing about gardening, you may be so focused on explaining how to perform grafting that you use terms for plant parts with abandon. Not everyone is familiar with these terms.
Improve your technical writing by providing a glossary of terms so that your reader can just reference to it.
Sample case no. 2: Assuming prior experience
To demonstrate its effect on the writing, let’s look at a sample scenario.
Some companies sneakily make assumptions on purpose. This, of course, leads to wastage and frustration. For instance, a training company advertised a data processing course for engineering students. However, they didn’t disclose that they’ll use the programming software MatLab. Thus, when the course started, half of the students found that the course is of no use to them as they haven’t learned MatLab just yet. When confronted about it, the company fired back by saying that the students should have known since it’s what data processors in their area use, anyway.
Don’t be that company. In technical writing, state everything you assume about the reader to avoid situations like this.
Sample case no. 3: Hybrid products
In today’s society where everything is getting more and more efficient, hybrid products are on the rise. For example, there are now “cleansing conditioners” that function both as a shampoo and a conditioner. As a user accustomed to the double step, you know how to use these products individually. But what if you’re just starting to shift? Should you use this shampoo-conditioner hybrid like you would a shampoo (that you focus on roots and rinse immediately) or a conditioner (that you focus on the ends and leave on for 2 minutes)?
In technical writing, the user document for this product should discuss the proper usage. Most do not and assume that the reader knows already.
Some final notes regarding the reader experience
Another common area in technical writing where reader experience is assumed is when it comes to injecting humor into the document. Humor relies on two things: a certain level of mastery of the language and prior knowledge of the subject. Thus, humor may not be effective when it comes to technical writing. Because it’s only going to confuse readers who do not understand it, attempts at humor is discouraged.
After all of these examples presented, you should have learned one thing: minimize assumptions about reader experience when doing technical writing. And if you must, clearly declare what you have assumed about the reader. Add the information you assume (like adding a glossary) and tell your readers where to find this information. By doing this, you increase your credibility and in turn, your readership.
I hope this article has given you awareness about how your assumptions may clash with reader experience. Supplementing your user document to combat incompatibilities is a big step towards great technical writing.