Shanghai Tech Writer

This past few weeks have been extremely busy as I have been wrapping up a project and preparing for my next documentation project. This new project is a new toolkit for LabVIEW. I am quite excited because this will be my first 1.0 documentation set, and I will be responsible for writing the entire documentation from scratch! I will get to see and be actively involved in the whole documentation process from beginning to end. In addition, I am responsible for making decisions on the type of documentation and content that will be shipped with this new product. It’s a huge responsibility and I look forward to the challenge!

As with any documentation process, the first step in starting a new documentation project is to create a documentation plan. A documentation plan is basically an overview of the entire project plan from a technical writer’s perspective. This plan is created early during the project research phase and integrated with the overall project plan so that everyone including the project managers, the developers, and the technical writer(s) are on the same page. This plan includes an overview of what the product is, the purpose or the goal(s) of the documentation, the key contacts and content experts, the target audience/users, the risks and challenges, the type(s) of documentation, and the project schedule. The documentation plan provides guidelines and directions for the technical writers as they create user-centered documentation.

Here are some basics to writing a documentation plan.

1. Overview of the Product / Project—This section introduces the product that is currently being developed, what it is, what it does, and how it is or can be used.
2. Purpose of the Documentation—What are we trying to accomplish with this documentation? It is important to have a sense of purpose and direction for the documentation. Examples include minimizing tech support, improving user-experience, and providing more procedural help.
3. Identifying Key Contacts—Identifying everyone on the development team so that everyone knows who is responsible for what. The key contacts include the project manager, the content experts, the marketing manager, product support engineers, and the technical writer(s).
4. Defining Target Audience—It is important to know who the target audience or users are. Knowing who will be using the product helps technical writers, as well as content experts, structure, organize, design, and create user-centered documentation and product.
5. Identifying Risks and Challenges—A good plan needs to be able to identify risks that might occur as well as have plans to mitigate the risks. Things like unexpected delays, time constraint, inexperienced writers, vacation/holiday schedules, maternity, and health-related issues can impact the quality and outcome of the documentation.
6. Defining the Deliverable—Knowing the purpose of the documentation, identifying who the target users are, and understanding the nature of the product help determine the type of documentation that are needed. The types of documentation include online help, print document, embedded help, conceptual help, procedural help, video tutorials.
7. Creating a Documentation Schedule—Part of the documentation plan is knowing how the documentation schedule fits in with the project schedule and the product life cycle. A technical writer needs to know how much time he/she has to do research and when most of the content should be written. There should be enough time for the documentation to go through several rounds of review.

(1 votes, average: 5 out of 5)

 Loading ...

  Subscribe to RSS feed       Subscribe via e-mail