If you’re in the business of developing and selling products that are in any way technical in nature, you probably spend most of your time planning or implementing specifications, development and release schedules, budgets, and engineering strategies. Or you may be directly involved in the day-to-day development and testing of the product. Whatever your role, the product is the most important thing. After all, if there’s no product, there’s no business.

In all of the things you have to think about, have you thought about bringing a technical communicator into your team? The realm of technical communication involves many job types, but in this particular context, I’m talking about a technical communicator who produces documentation that is intended to be distributed to the product’s end users. That documentation may take the form of online help or other Web documents or printed documents. Sure, a tech communicator may be another body taking up project budget, but here are seven reasons you should work a technical communication team member into your budget and project plan.

I: End Users Need Documentation

Simply put, users need to know how to use your product before they can actually use it. Some learn by trial and error, but others learn by reading the instructions. Some solve problems by calling technical support, but others want resources at their fingertips that allow them to quickly find the answer. Even something as simple as a quick-start guide for a product is enough, and some users will never need to look at any more lengthy documents. But others do.

In a recent questionnaire I distributed to users of one of the applications I document, I asked them to rank several options in order of their preference when it came to getting answers to their questions about the application. Calling technical support rated very low for most respondents. Asking a coworker was the highest preference, but consulting some form of documentation was also ranked highly.

Perhaps your product is intuitive. It stands on its own and speaks for itself. The engineers may tell you that, but what is intuitive to someone who deals with schematics or programming code every day is not necessarily intuitive to an end user. The job of a technical communicator is to take technical material and make it understandable to the least learned user. In addition, engineers are engineers, not writers. In general, they want to engineer, not spend time documenting the product. Because they don’t want to do it, they most likely will not give it the attention it deserves.

II: Technical Communicators Look at the Product with a User Perspective

Continuing participation of designers or architects and stakeholders who set requirements helps keep the project focused on meeting users’ needs. However, this is not always possible or is not part of the company’s development strategy. In either case, having a technical communicator on board gives the end user another voice because the technical writer’s job is to think constantly about the user and what he’s thinking. When I think about what the user needs to know about the product, what questions will come up, and what problems will need solving, I think about how the user interacts with the product. Sometimes that results in feedback from me to the designers or developers. This helps keep the end user in the project team’s consciousness. Even small tweaks can improve the user’s experience.

Advertisers or marketers think of the user, but their job is to convince the user that she needs your product. A technical communicator will help the user stay convinced. Even if a user has no option but to use your product, having quick access to information about how to use the product will make that use a more pleasant experience.

III: Technical Communicators Help with Quality Assurance

For a technical communicator to effectively document a product, he should understand it thoroughly (or at least as much as the user need to understand it). The best way to accomplish this is for the technical communicator to have access to the product, preferably a test version, so he can exercise it. Having requirements or specs is good, but being able to work with the product as well is better.

While the technical communicator exercises the product, he may come across bugs or other problems that the quality assurance team may have missed. Many times, testers think about making sure the product does what the requirements say it should do. But an end user may not use the product exactly the way it’s intended. As the technical communicator becomes familiar with the product by using it, he may exercise it in ways not covered by test scenarios.

At the very least, a technical communicator’s editor’s eye can catch text problems and give corrections. There are those end users who lose respect for an organization when there are textual mistakes in or on the product.

IV: Having Quality Documentation Reflects Positively on Your Organization

When documentation accompanies your product, you are communicating to the end user that you care enough about her experience that you have provided help or instructions for her use. Personally, if I purchased software with no installation and use instructions or an assembly kit without assembly directions, I would think that the source company was skimping. I would think that that company was cutting costs to maximize profits though it meant making my life more difficult. I bought the product to somehow benefit me, but having no guidance on how to use it in fact has the opposite effect.

Providing documentation tells the user that you value her business and personal success enough to provide every helpful resource you can.

V: Documentation Provides a Record

Sometimes, your product may be complex enough that it’s not intuitive even for the engineers. I have worked on an application that is complex not because it was badly designed, but because it was built to accommodate complex business processes. Writing documentation has provided a record for the designer and developers on the decisions made. More than once, a member of a development team has asked about a specific parameter in the system, and I could answer because I had documented that parameter. The documentation explains the final product to everyone. This saves the engineers the trouble of writing their own documentation unless they need something of an extremely technical nature that is geared toward other engineers.

VI: Documentation Saves on Support Costs

No, technical communicators are not technical support agents. One is predictive, and the other is responsive. But because the technical writer has approached the product from the user’s perspective, she has anticipated some of the questions the user will have and provided guidance on completing tasks the user needs to accomplish. When the end user refers to documentation and finds the answer to his question there, a support call has been averted. Documentation can cover common questions and problems, and support becomes freed for more serious user difficulties.

VII: Technical Writers Have a Versatile Skill Set

Technical communicators are writers, editors, and many times graphic artists at some level. Perhaps you have a letter or email that needs to be sent out, but you’re sure the document could use a little spit and polish, and you know a technical communicator sits two offices down the hall. Most technical communicators would not have a problem with taking five or ten minutes out of regular work to review a memo or other document. Just remember to be respectful of her time—she has deadlines, too.

Though at times regarded as an expendable luxury, technical communicators are essential elements of product development. You’re in business for the end user, and a technical communicator brings that truth home in a way that contributes measurable value to the product.

For more on this subject, see Four More Reasons Your Company Needs Technical Communicators.

Related entries (auto-generated):

Four More Reasons Your Company Needs Technical Communicators

The Technical Communicator Getting Involved in User Forums

The Technical Communicator as Project Manager

Project: Reasons for Technical Communicators

Follow-up: A Skill for the Extroverted Technical Communicator