| February 2006 |
| By Sarah Hogan |
Technical communication is one of the most mysterious technical fields you can venture into. You’ll never be sorry you kissed that $8-an-hour reporting job goodbye, but you will often discover that your role requires a lot more effort and dedication than you expected. For the purposes of this article, we’ll focus on technical writing in the software industry, which is one of the many roles a technical communicator can play.
How do technical writers improve technical communication?
Because most people have been exposed to documentation that is written by untrained authors, their expectations of the manuals that ship with a product are poor. Some companies supply a manual only as an afterthought. They depend on engineers or untrained full-time writers to create their documentation, which often turns out to be ambiguous, disorganized, and uninformative. Engineers typically speak to a higher audience than the target audience, and untrained writers have none of the engineer's technical skills and little understanding of how to interpret and translate technical concepts into a coherent piece of writing.
As a technical writer, you are responsible not only for producing documentation people can use, but also for producing documentation that adds value to your product. When you are writing, keep four basic guidelines in mind:
1. Focus on the user.
As a technical writer, you are the one who focuses on the user. You will drive your peers crazy with such phrases as “But what will the user see?” and “How does this feature benefit our users?” and “Hey, let’s set up some usability testing.” Ignore the eye rolling and guffawing. Users are the only reason your company produces software, and you link the software and your users.
When you focus on users, you are able to specifically target your audience. For example, is your audience a group of programmers? Programmers possess a higher level of expertise than do end users. When you and the members of your writing team have a clear understanding of your audience and their expectations, you are able to produce solid instructions for the tasks your users need so they can - you hope - use your product.
2. Produce consistent documentation.
Besides controlling some of the obvious consistency tasks, such as ensuring that you follow a careful review process, you are responsible for reflecting your company’s goals and culture.
For example, you know when you’re looking at something Adobe Systems has developed. That’s because the technical communicators over at Adobe know a lot about branding. Any communication that was blessed for release from the Adobe compound possesses the same look and feel as every other piece of documentation.
As a technical writer, you are charged with establishing and protecting your company’s branding and look and feel. Not only are you responsible for designing books that look the same, but you are also charged with ensuring that they follow the same organization so that your readers know where they need to go to obtain certain information.
3. Work collaboratively to produce great documentation.
You might have a favorite fantasy in which you are writing your user guide from a cabana in the Virgin Islands. Alas, that’s the technical editor’s job, and you as a lowly technical writer must fight just like everyone else from the trenches in the office. Not only do you need to develop strong rapport with your Subject Matter Experts (your SMEs - and you develop better rapport when you do not call them “SMEs” to their faces), you must attend every meeting to ensure you can throw in your two cents’ worth about the users, and you need to have constant (if possible, dedicated) access to the software you are writing about.
4. Understand the developments in your field.
You can’t produce good documentation if you don’t know how your readers want to receive it. New advancements in communication are coming out every day, and if you are unfamiliar with XML, online Help tools, photo-editing software, or other documentation software, you might soon find that your users are abandoning your company for someone who uses hipper, trendier tools. After all, if your company is unable to produce a manual your users can use, what CAN your company do for them? If you can’t update your documentation as quickly as Company B, why should users invest in your company?
Why should you be a technical writer?
Technical writing an exciting and dynamic field for good writers. Ultimately, you ensure your SMEs can put their great ideas into service for the public. If you get a position at a good company, your peers recognize your value, and they are eager to help you produce documentation you can be proud of.
Sarah Hogan is a former technical writer. She is now a technical editor who edits documents from her laptop in the Caribbean.
If you would like to submit an article providing an insider’s view of your tech or engineering job, please send your article to us at ITtrenches@dice.com.
Comments on this article? Share your feedback on our discussion forum, Dice Discussions.
*Please note, you must be a registered job seeker in order to submit your question to Dice Discussions.
|
|
|
