A technical communicator creates content to clearly communicate information to the intended audience.

The Ninja

Anyone who has studied technical writing knows that audience is king. Everything we do is tailored to the needs of the audience we serve. That single point is the reason that we have been led to branch out beyond simply writing the content. If your audience learns best through reading a book, it makes sense to develop a book that contains all of the information your audience needs to use your product. Anyone remember the jokes about their documentation being sold by the pound?

Today's audience has different needs; media is consumed in more ways than in the past. It is more common today for a reader to view your help content on a smart phone than on their computer. Or to use a tablet instead of a full-szed computer. Those of us who have been around longer may still prefer to read (I can consume content much faster by reading than by listening, for instance) but more people are showing a preference for listening to spoken content or to watching the information presented in a video. Because of these changes in audience preference, technical communicators must adapt and learn new tools.

Returning back to the discussion I had with my associate. When i began this path nealr 20 years ago, I wrote and edited content that was presented as printed text or on a Web page. Someone else handled the styling and the production of the finished product.

Today, producing my content might include any or all of the following:

• Writing content
• Editing content
• Designing the cascading style sheets (CSS)
• Writing HTML, XHTML, XML, etc
• Managing the publishing of a single sourced document to multiple channels
• Graphics manipulation
• Video production
• Audio production

At this point in my career path, I handle any or all of these aspects for a project. Throw in a measure of project management and negotiation, shake well, and serve warm.

Does this mean that the newbie technical writer MUST learn all of these skills? No. But I believe that you should be conversant with as many of them as possible to succeed as a technical communicator. And always be open to new ideas, because who knows where the audience will lead us in the future. We must be equal to the task and strive to deliver the content the audience wants when they want it and in the manner they expect.

We don't always have the luxury of having a trusted editor review and improve our work, especially if your team is on the cycle to peer-review or self-edit all work. Or perhaps you are working alone, writing the website that will expose your editor's obsession with their imaginary friends and have to edit the writing yourself. Whatever the case, there are times when the technical writer must editor his or her own work, so how do you avoid the mistakes that you just can't see? And why do we make those mistakes, anyway?

Writing is the practice of recording thoughts; words, sentences, and so on are just thoughts. We describe our world in our own thoughts and use words to describe what we see there. When we write something down, we are recording our thoughts for someone else to read so that they may understand the subject as we do. If you make a mistake while writing, you may not see it because your thoughts are in the way. What I mean by this is, you know what you meant to say so strongly that when you read the text you're actually replaying the thought in your mind rather than reading what is literally on the page. So editing your own work becomes a process of tricking your brain into viewing the text differently than when you wrote it.

I've learned a few techniques over the years to help me see the actual text rather than what I thought I wrote, and here are the ones I use the most.

1. Read it Upside Down

2. Read it Backwards

This technique works the same way for tricking your brain, but may be easier if you have trouble managing the inverted reading. In this case, you read the words in reverse order. You can start from the end of the document or at the end of a single paragraph and make this work. I personally prefer to work with a single paragraph, because I can still maintain some sense of the document's overall flow while editing individual paragraphs.

For example, the normal direction text:

This is an example of backward editing

Would be read as:

editing backward of example an is This

3. Give it Some Time

My last suggestion, and the easiest of all provided you can do this under your time constraints, is to simply put the document aside for a day or two (a minimum of a few hours) and then make your editing pass when the thoughts aren't so fresh in your mind. This will let you approach the work with fresh (-er) eyes and thus see the mistakes that would otherwise be concealed from you. After all, the reviewer who sees your mistake isn't necessarily smarter than you, they just see your work without preconceptions.

In the grand scheme of things, this was a trivial point to get hung up on. I fixed the structure by changing it to:

You should use the branded service...

Once I was satisfied that my dignity as a technical writer had been sufficiently preserved by obliterating the offensive use of passive voice I sent it back for his review. He sent it back and requested (again) that I make it more like his suggestion. My temper flared. How dare he ask me twice to use passive voice! To get a grip on myself before committing ritual career seppuku by verbally slapping a senior manager, I reached for a Klondike Bar and considered the issue. That helped, but I was still irritated, so I went back for another Klondike Bar. After letting things percolate through my subconscious for a while I took another look at the manager's suggestions. How badly would it damage the fabric of reality if I simply took his suggestion? It would make my customer happy... And then I saw the problem. I was so fixated on the voice of the suggested text that I was missing a subtle change in meaning later in the sentences. Aha! perhaps I could satisfy both the customer and my sensibilities.

First, I fixed the voice to be direct and imperative. Next, because my document was for the intended audience of resellers of our company's services, I felt it would be better to remove the word "reseller" from the suggested text. After all, the audience would understand who they were, right? And then I focused carefully on the actual change in meaning that my customer was asking for. I sent it back to him in email (humbly and with no customer-slapping involved) and he was very happy with the new version. With that out of the way, we could move on to publishing the document and everyone was pleased.

Have you ever found yourself in a circular review cycle where both sides are irritated and feel that they aren't being heard? I think it would be worthwhile to take a step back and ask yourself What happens if I simply do exactly what they're asking? just on the chance that you are doing the same thing I was. If you are getting caught on a sticking point, you might just be missing the meaning behind the request from your reviewer.

And if all else fails, have a Klondike Bar and give it some time before you answer.