Would you set out on a road trip without looking at a map? Would you sit down to write code without knowing what you are building and how you will go about it? Of course not! You want to make a plan when you’re writing prose, too.
The first thing to do is identify your audience. Think about whether they are IT people who need instructions, managers who need to know how this product differs from another, developers who need to incorporate this product into their own or customize this product, or maybe they are absolute beginners who have never touched a keyboard. Think about how technical you need to get before you write anything.
Once you’ve identified your audience, create an outline of the discussion. Document how you will introduce the topic, pursue the discussion, or build the project, and draw a conclusion or two. You can use phrases, sentences, or subheadings—it doesn’t matter, so long as the map you make is meaningful to you. You may need to deviate from your outline when you start learning about the product’s features that are new to you, but if you start with a map, you’ll still end up where you want to go.
Now review your audience again. Does your outline answer the questions this audience might have? When you’ve got an outline--just the skeleton of your work—you can see whether or not your discussion is linear and whether each heading answers the promise made by the title.
Now you’re ready to write. Don’t worry about starting at the beginning and writing to the end. Pick one of the headings that appeals most to you, and start there. You’ll spend less time revising your introduction this way. Thanks to word processors, you can write in any order that pleases you, and writing this way can also prevent the dreaded “writers' block.”
Pick and choose your way through, until you have written the whole thing. You might want to create a style sheet (more about these in a future blog), to be sure that your references to the product comply with the manufacturer’s preferences, that you’ve spelled things out or used acronyms consistently, and that you don’t use e-mail in one place, email in another, and Email in the rest (and that sort of thing). Style sheets may already exist for the product manufacturer, and it’s a good idea to ask for one. Style sheets are a laudable way to prevent the inconsistencies irksome interruptions, like when your boss swung by with a new assignment or the kids needed a fourth for a game of catch, and you had to pause in your thought process. When your references are consistent, your reader won’t know that you didn’t write the piece in a single sitting.
Check the number of words you wrote against what you were asked to write so that you know whether to edit for length when you are checking your work.
Once it’s written, reread your work. Plan to make several passes. Read it once at least, to make sure that you answer the promise made in the title, that your discussion is linear and your headings clear, and that you didn’t make obvious mistakes. Read it again looking for grammar and punctuation mistakes, and that your tone and references are consistent. Read it again to make sure you don’t say “I did this” and then “you do this” when you’re giving instructions. Read it a final time, and see whether it flows nicely. If there’s time, put it away for a day or so, and give it a final brush up before you turn it in.
Making a plan is easy:
1. Identify your topic
2. Identify your audience
3. Write an outline
4. Check the audience again
6. Check for length
I’ll write more on identifying your audience, outlining, and style sheets in future blogs.