A few months ago I posted seven reasons an organization needs technical communicators. This week, a program manager I work with provided a few more ways that technical writers provide value to organizations and projects, so I wanted to pass along his wisdom—with my own discussion, of course. Because I gave seven reasons before, I’ll start with number eight.

VIII: Technical Communicators’ Information Gathering Gets the Team to Think Critically

In many projects, the designers have participated from the beginning, and it becomes easier over time to become focused on the development side. The developers are thinking about providing the product as designed and aren’t concerned as much with how well the product meets the users’ needs; they trust that the designers have taken care of that.

Then the technical communicator comes on the scene. As he asks questions about the product and how it works, he is thinking about the user’s perspective—and he brings his own fresh view to the project. His process of information gathering causes the design and development team to look at the product the way that users will and to recall and reevaluate the decisions they have made. This can cause them to either reaffirm their decisions or make some adjustments that will benefit the user.

IX: Technical Communicators Are Specifically Trained

This point holds true for any professional: If you have hired someone with training and experience in the field for which you’re hiring her, you’ll get better results. You wouldn’t hire an attorney to draw up the blueprints for your state-of-the-art gym. You also wouldn’t ask the plumber to fix your electrical problem just because he had already stopped by. In both cases, you’d have to wonder about the quality of the results.

Similarly, documentation quality suffers when developers, designers, or business analysts produce it. They are trained for their own responsibilities. Technical communicators are trained to speak to and instruct the user on the user’s level. While technical writing relates to other disciplines, it is its own field and job function requiring specific skills. You’ll get a better documentation product when you have someone who has those skills.

X: Technical Communicators Lighten the Load

Managers many times do recognize that their products need some sort of documentation to meet some unspoken requirement (or perhaps the customers ask for it). But without a clear idea of what should be involved, some managers turn to the team members they already have to produce the documentation as referred to in the previous point. They ask the business analysts or developers to do it.

These folks have other responsibilities, so documentation requirements are nothing more than another bundle of straw on the camel’s back. It will be pushed to the nooks and crannies of the person’s schedule; or, if that person is a perfectionist, the documentation project may push him to the limits of capacity as he makes an honest go at it.

With a professional writer, the other team members don’t have to worry about cramming documentation work into their schedules other than to spend a few minutes at a time with the writer. They can focus on their primary job functions. They would rather have someone else do the documentation anyway, so they’ll be happier that they’re not asked to do it.

XI: Technical Communicators Can Provide Training and Support

As I mentioned in some early posts, I have been asked to provide live user training, both in person and over the Web, because as the technical communicator on projects, I understand the big picture and also many of the details. If you don’t have professional trainers on hand, and your technical communicator has good presentation skills, you can use her in the training role.

Though user support can take a lot of time, you may also get your technical communicator involved in addressing users’ concerns and questions. This model works particularly if your organization does not have a service desk, the service agents can’t be specially trained on all of your products, or you have a relatively small user base. This point returns to lightening the load: If your business analysts, testers, and developers are spending time on support, the technical communicators can take part in that effort to spread out support time further so everyone can focus more on primary job functions.

No related posts.