Recently, I was asked to edit some product-related legacy documents. The manager wanted me to remove the mistakes in those documents and make those “sellable.” Although, the tasks was a routine work for me, something in it made me write this blog post. But, what could be wrong in an instruction as straight forward as the one in the following screenshot?
As a reader, I find nothing wrong with the paragraph. But, it just doesn’t sound correct when I listen it from the ears of a technical communicator. This set of sentences is from one of the legacy documentation, which I was supposed to make “sellable.” As I continued to dig into the documents, the urge to edit them continued to become stronger. So, I searched through the internet for information.
Parallelism, as I figured, was missing in those documents. As I learned, Parallelism passively contributes in comprehension. As mentioned on Wikipedia, it helps in creating uniformity and balance with the use of the same grammatical structure within a sentence (or across a set of sentences).
Here’s another example from the legacy documents for reference:
The –ing form in “employing” doesn’t go well with “enables you to test” because the structure is changed. As writers, we must pledge to follow a consistent structure. And, as editors, we must carefully look for (and correctly change) such sentences. Based on my analysis of what I read, it looks like the parallel structure works at the following two self-explanatory levels: sentences level and paragraph level.
For now, let us overlook the other mistakes and concentrate on only the highlighted sentence. If I wrote the highlighted sentence, it would looked like: “Thus, employing a test environment helps you in testing whether your routine tasks and processes are working properly.” Or, if using gerunds in instructions sounds as odd to you as it sounds to me, I have another version for the same sentence: “Thus, a test environment helps test whether your routine tasks and processes work properly.”
As an editor, I must not make a lot of changes in the writer’s work, but I still must improve the quality of content (and consequently help improve its comprehension). Similar to the grammatical structure in the above example, given the chance, I would write the paragraph in Screenshot 1 as follows “The System Setup chapter provides information about creating a manufacturing company and integrating it with a finance package. You can use this information in creating user groups and assigning access privileges to users.” – Without making a lot of changes in the original draft from the writing team.
Now, I’m neither a perfectionist nor a stickler for rules. But, I expect quality in what I either read or deliver. And, the task of rewriting any documents requires more efforts than writing it correctly in the first pass. That said, each task has some unwritten guidelines. And, we [as technical communicators] do such tasks every day. We’ve talked about the editor’s role before. But, like I said, this is an unwritten guideline!
If as an editor, I am picky towards the mistakes that my writing team commits, as a writer, I must first pledge to not commit the same mistakes. This is what I think (and have read) on parallelism. What about YOU? Have you come across any such issues in your legacy documents? What are YOUR thoughts on using parallel structure in technical communication? Are the thoughts parallel to mine? Let me know.