Pulling in a Fresh Technical Writer on an Old Product
When a manual or online help system needs to be reworked or rewritten because it’s not working well for the users, completing the project might seem simple on the surface. After all, the past writer(s) who wrote the documentation already know the information inside and out, so refining and reworking the text should be simple. Right?
The problem with using the same writers to describe software they’ve documented in the past is that they can often write the material from their own point of view, and they might not be considering the users in the audience, whose needs may have changed since the original material was first written.
It’s similar to an HR manager’s description of a job versus a worker’s description of the same position. Both descriptions may be technically correct, but they might not seem the same to someone who’s not familiar with that position.
When documentation needs to be rewritten, there are two important considerations for who will be tasked with the chore of completing the project:
- The chosen writer needs to be fully familiar with the product – It goes without saying that a new writer will have to become familiar with the product. But if the original writer is available and hasn’t actually used the product or its documentation lately, he or she should spend time learning more about it using a fresh perspective. This perspective should be form the point of view of a new user. Rewrites and updates also present a cross-training opportunity for a writer who has never used the product before. Having both the new and the old writers working collaboratively can sometimes provide the best end result because you get to combine the knowledge and experience of the original writer with the inexperience of the new writer and they can help keep each other in check.
- The writer needs to have a good understanding of today’s audience – This is common sense, of course, but is sometimes overlooked. If customers aren’t satisfied with the documentation it may be time to get better insight on today’s actual audience for the material. Not every technical writer has a strong grasp of the needs of their audience, so it may be that the original writer missed the mark in this area. It may also be that the original assumptions about the audience were incorrect. In that case, a fresh writer may be the best solution. The writer who is not familiar with the product will be looking for information, and during that process can learn a lot about what is available, what isn’t available, what could be organized better and what is confusing to a new user.
On the whole, technical writers are very good at explanations: It’s what they do. But their explanations need to be written for the audience, not for themselves. Even if the descriptions are technically accurate, they may be confusing to users, especially new users, who are likely to get bored, get confused, or both.
What often happens is that users get to the point where they become so frustrated with the documentation they stop turning to it for information.
Getting, and fully incorporating, user feedback is important. That said, when it’s time to rework or rewrite the documentation, it’s not about getting rid of the seasoned tech writers, having a fresh point of view can have a substantial benefit, not only for end users, but for everyone on the team.
What are your thoughts? Please leave a comment.