You, a non-writer, have just been assigned to write the documentation for a product your company produces or markets. You may be stressed out about the assignment. Fear not! This article will get you started on the path to writing a successful document.
OVERVIEW
You, a non-writer, have just been assigned to write the documentation for a product your company produces or markets. You may be stressed out about the assignment. Fear not! This article will get you started on the path to writing a successful document.
QUESTIONS AND NOTES
As soon as you get assigned to the documentation project you must begin to take notes and ask questions. The major goal of this early information gathering is to gain access to the sources of information that you will need in order to write your document. Thus these early notes should be related to where you will get your information: things to read and people to contact, and a product to play with.
TIP: There is always something to do or learn on a Documentation project. Don't stop working while you are waiting for something else to happen.
LEARN PROPER USE OF YOUR WRITING TOOLS
Do NOT get immersed in new technology. For most companies and for most documentation projects, investing the money and time to learn a Content Management System or exquisite document writing software are not worth the effort. Documentation writing is often the tail end of a project, and you will have no time to learn new technologies. Instead learn to get the best from your existing word-processing tools.
Learn about and understand why you should use your word processor's "styles" for formatting your document. "Styles" (or whatever your word processor calls them) are sets of characteristics such as a structure and formatting. For example, Heading (level) 1 is a style, Heading 2 is another style, and so are Title, Body Text and others. When you apply a style to a block of text, two things happen:
(1) the formatting of the style gets applied to the text and (2) the word processor will be able to understand the structure of the document. The word processor's tools will use the headings to automatically generate a table of contents.
You will have to be able to deal with revisions from multiple reviewers for each part of the Document. Most word processor Users do not know how to use the revision system that their software provides. You might wish to create a document about the revision system for your reviewers. Remember to tell them what the revision system is about, as well as how to use it. Technology comes second. Our goal will be to produce a great document, providing the:
DOCUMENT ALL PEOPLE ON THE PROJECT
Pretend that it is 10 years from now. You or someone else must re-write the User Documentation for the product you are now working on. You or someone else must be able to contact those who worked on the original project or the people who replaced them. You may need to ask them questions, or at least to find the notes and other background material related to the document that they produced. You must keep a record of everyone who worked on the project (for the product itself and for the User Documentation.)
The people who are working on the project include (there may be others, include them in the list):
You should keep (for yourself and the entire project team) the following information. It should have an entry for every person inside and outside the organization who is affiliated with the project, and these data:
DO IT NOW: LIST THE PLAYERS
Create this list of everyone related to the project. You can keep the list using a word processor, spreadsheet, or dedicated address-book software and in your e-mail program. Use whatever method you are used to using (a computer program is best, as it permits you to edit the list, and to share it with the other members of your project team). Include the information I suggested above about each participant. The goal is to know who worked on the project, their role in the project, and how to contact them.
Keep the list up to date. YOUR PATRONLet’s call the person that assigns you the task of writing the document (or a portion of it) your "Patron". This is the person who is responsible for ensuring that the documentation gets produced. There are several things you must ask of your Patron, and you must carefully note the responses. Ultimately, your Patron must provide you with (or put you in contact with someone who can provide you with):
Not only the names and contact information, but also provide the “clout” to get these people to provide information to you. This is vitally important! This access must include the marketing and design teams. They can tell you about the potential Users of the product.
So you can gain some hands-on experience with the product.
Access to Users of similar products; access to potential Users of this product (or information about them)If you have been hired by, for example, the Human Resources Department of the company, then Human Resources will have to direct you to the person on the project who is your Patron. Your Patron is not your client. In the business world we speak of our "client." That is usually the person or organization that hires and pays us. It's the one we are working for. However in reality your client is your Reader. It is your responsibility to do the best job for your Reader. If it's necessary to go against the judgment of your Patron then you must be prepared to convince your Patron of the merits of your way of doing the work.
Read all the material you can get about the product and the project . It will prepare you for the interactions you will have later with the project members. Be prepared by knowing as much background information as you can before you have your first information gathering session (meeting). Ask: "What can I read or do in order to get the background on this topic?"Even if you are the developer, there are things you need to learn. One of the most important is concerns the characteristics your potential User.
Your early investigations should be aimed at answering these questions:
1. Overall (brief) Description of the Product.
What does the product do for the User; How does the product change the way the User currently does things.
2. Intended Audience (the Users) for the Document and the Product This is the "target market" for the product; information about who will use the product. This information could come from the marketing and design groups for the product. Ask them: "Tell me about your potential User of this product?"
3. Goals of the Document that You are Writing This is the "scope" of the document…what is your document supposed to deal with regarding the product. See the next item on this list, item
4. Is your document to be a User Manual, Reference Manual, Setup Guide, or a combination of these? 4. Are there to be any other User Documents to be produced that are related to this product? That is, is the document you are working on a portion of the User Document set that the organization will produce for the product? If yes, what are the other documents in the set (so you can refer to them in your document)?
5. The contact information that I discussed just above. For every question you might have, you must have a source (be that source written or verbal) for an answer.
The items on the above list would probably be answered by “higher level” members of the project team. Perhaps your Patron can answer them; if not, he/she must guide you to where (or from whom) you can get the answers. These are the first things you will write about in your User Documentation. Get this information early in the project. In short, you need to get both written documentation about the product and contacts who you can ask to provide more information.
Eventually you will enter this information in a word processing document that you can share. Document all of this information.
ASK ABOUT MECHANICS
Very early in the documentation project you should ask your initial contact about these writing-mechanics topics:
For example, the style guide for the indexing community says that the plural of "index" is "indexes," not "indices." A mathematical style manual would select "indices" as the plural of "index." If your company has adopted a style manual, use that one, if appropriate to the product. If not, search an on-line bookstore for "Style Manual" or "Style Guide" and your industry, such as "Style Manual Mathematics".
Keep track of all this information. You will organize it and add to it as you this documentation project moves forward. GIVE SOME INFORMATIONYou should give everyone your contact information so they can get in touch with you. You might consider using your business card, and writing on it that you are writing the User Document for whatever product. Make it easy for your contacts to get in touch with you. Ensure that you have your contact information in any e-mails or copies of the document that you send to others.
You should also tell your Patron how you plan to write the documentation. You will be writing the document in pieces (which are logical topics or modules), and provide the pieces to members of the product team for review. Also (unless you are a professional writer, in which case you may do most of the editing yourself) make it known that you plan to use someone else to edit your document. Interim materials that you provide might not be edited; you are providing them in order for reviewers ("experts" within the project team or marketing) to evaluate them on completeness and accuracy. You will ensure clarity of the writing in the (later) cycles of editing and revision.
One of my (ideal) goals for you is that you become the focus of all the User-oriented information about the product. You become the resource that others on the project turn to for information.
I believe that you should provide information to those involved (and especially those to be involved at a later stage in the project, such as the indexer) as early as possible in the life of the project. There are several benefits to this:
SET UP AN INFORMATION SHARING RESOURCE
I believe in sharing information...it makes for a better work environment and a better product. Use whatever available technology you have to create (or get created) some kind of resource to share information. This information will be in the form of computer files...nothing magic.
You may be able to use a shared directory on a local network, or a protected area on your company's intranet. Investigate what is needed. Provide read and write access to all the people (inside the company) who are involved on the project.
One of the first things to post is the list of people on the project. Make sure that whatever you post, it is in a form that everyone who has access to it can read (and possibly write) it. NEXT STEPSOther articles in this "New Technical Writer" series will assist you as you progress through the writing project. Look for them in the links in the "Resources" section.
Great Technical Writing: The User-Product Life Cycle - A Documentation Tool
The User-Product Life Cycle (U-PLC) is a powerful tool for the User Document writer. Use the U-PLC to generate the high-level topics for your User Document.
Great Technical Writing: Tell Your Users What to Expect
In your User Documentation, you direct your Reader to perform tasks with your product. If you don't tell your Reader what to expect when performing those tasks, you will have a baffled Reader, resulting in dissatisfaction and expensive calls to technical support.
New Technical Writer: Conquering the Fear of Writing
Stepping into the role of a technical writer can be daunting, especially for those without a writing background. The task of creating User Documentation for a new product might stir up fear and anxiety, reminiscent of school days filled with writer's block and critical evaluations. However, writing for a user manual is a unique process that differs significantly from academic writing. This article aims to guide new technical writers through the process, providing strategies to overcome anxieties and produce effective documentation. With the right approach and resources, anyone can craft clear and helpful user guides.
