Who Should Write the User Manual

Who Should Write the User Manual?

IIn the last three articles I discussed many of the issues you should explore when planning software documentation. (Remember that these principles can be applied to any type of documentation.) We’ve covered the general need to plan your manual, including knowing your audience. We have also talked about how to organize a manual and how page design can increase readability. Well, you also need to decide who will write the manual.

Of course you know that you have to decide who will do the writing, but you may have more options available to you than you think. Your company may have a publications department with writers on staff or the department may contract with freelance writers to do the work. Using the expertise of your own publications department should make your job easier because the staff is experienced in handling these types of projects.

If you don’t have a publications department, or don’t want to or can’t use them, you need to look at other options. You can have one of the programmers or someone else from your staff write the manual. This may seem like the best option since someone from your own staff is already familiar with the system. While this may be the easiest and fastest approach, it may not be the best.

Many programmers do not want to write the user manual and many are not good writers. Of course, there are exceptions and I do not want to insult anyone, but my experience has shown that many programmers find it difficult to separate themselves from their technical knowledge. This means that what they write may only be understood by other people with technical backgrounds and the novice user may be confused and frustrated.

If your audience is only technical people, this may not be a problem. Most systems, both in-house and commercial products, are more likely to have a mix of users. If you have a significant number of inexperienced users, you will be better off if you can find an experienced technical writer who will take the user’s perspective in writing the documentation.

If your budget is so tight that you cannot afford to hire a writer to do all of the work, you could have the programmer write the first draft. This will let you use your staff to get the system’s main features on paper. You can then have a writer reorganize and edit the draft. The writer will spend less time and you will spend less money.

If you use a contractor to do any of the work, you will need provide access to the system. The writer will need a copy of the software if it is a PC-based product. For other systems, the writer will need a login ID and the ability to dial in to the system or space at your facility with access to the system. You cannot write, or even edit, documentation without getting to know the system itself.

Now you may be wondering how to find a contractor to do the work (if that’s the route you take). Well, you should certainly talk with people you know and ask who they have used. You can also contact the local chapter of the Society for Technical Communication (STC). STC is an international professional organization for technical communicators.

If you are in the Denver area, you can go to the local chapter web site (www.stcrmc.org) and go to the Job Line page for instructions on how to post a job. You also have another resource in the Denver area, the Boulder Writers Alliance (www.bwa.org). From there you can use the membership directory to find a writer. If you are not in the Denver area, go to the international STC web site (www.stc-va.org) to find your local chapter.

In addition to deciding who will write the manual, you have to look at the tools available. If you’re hiring a contractor, you need to find out what software and hardware your writer has and if they meet your needs.

The next article will address the issue of what tools to use and other areas you need to consider as you make your decision.

intelligent technical communication from (writers@techcomplus.com)