Creating Documents Without Guidance

I've discovered over the years that vague assignments are either a joy or a pain for the professional technical writer. A typical scenario is something like this: your boss or customer comes to you and says, "We have X amount of information we want to get out, but we don't quite know what to do with it. Want to take a crack at it?"

To which I usually reply, "Heck, yeah!" and I dive in. Not everyone is so gleeful about such an open-ended assignment. The top two questions I've been trained to ask for any new document are:

1. Who's my audience?
2. What's the purpose of the document (i.e. how do I want them to react after reading it)?

Sometimes I might not get clear-cut answers to even that...the point is just to do information organization/design (More on that in a moment). In addition to the two questions above, there are usually two other questions that affect any document a technical communicator is called upon to produce:

• What form or format will my document take?
• What style will I need to use?

In general, the form and format will depend upon the amount of information that needs to be conveyed, while the style will depend on your audience.

But let's say, for the sake of this discussion, that you've received minimal guidance about your content except that the final product will be coming from your corporate president, senior project manager, or someone else near the top of the food chain. I actually enjoy this sort of assignment because it's challenging to think like the boss. You've got, maybe, 2-3 pages' worth (750 words, with or without pictures) of content, which might or might not be organized, and might or might not be on 2-3 pieces of paper...and you might or might not be familiar with the subject matter. Where do you start?

1. Read: Not to be a smart@$$, but you read what you've been given in whatever order it's presented to you. It might not make the slightest bit of sense, but you have to start somewhere.
2. Research: This usually means looking up or asking whoever you think might know what unfamiliar terminology means. Ideally you do as much Googling or sniffing through Wikipedia or internal publications before you ask. (I got burned on this a few times before a manager asked me, point-blank, "Do you ever look things up before asking?" Shame-faced, I went back to my cube and did my homework before asking another durnfool question.
3. Brainstorm: So now that you have the general gist of things...you know what the topic is, what's being said about it, and you know how much stuff you have to work with. Now it's time to take that extra 10 minutes to brainstorm about the pile of data in front of you and in your head. Take a stab at asking:
   --Who do YOU think the audience should be?
   --How do you think they would want to be addressed?
   --What's the most effective way to convey the information and get the reaction you (or your executive) wants?
   --What's the best way to organize the information?
   --How should the information appear visually? (This is the point where my friend Dr. OZMG suggested, "Use pretty fonts and emoticons!" And in truth, depending on your content, this might not be such a bad idea. Sometimes a clever visual gimmick, outside the usual corporate or institutional practice, is exactly what is needed to get your audience's attention.)
   
   Anything longer than ten minutes, either by hand-writing or making out a list on your computer, is probably wasting your time. Work with a peer or two if this helps you.
4. Organize: Take your ideas from your brainstorming session and put them into the order and (rough) format that most makes sense to you. This is where the technical communicator, in my view, can add value to any document. The trick is understanding your content enough to know what order or layout most makes sense for the user. Do you have something with a lot of steps? Then your content should be arranged chronologically. Do you have something that needs to be understood geographically or by layout, like a map or a new form? Perhaps you need to work with your graphics person to develop an easy-to-use "mind map" for your content to guide the user visually. Of course you might actually BE the graphics person; but even if you aren't, you should have some idea of how you want your content to appear--electronically or on the written page. Your graphics person might come up with ideas you hadn't thought of because visual imagination is much different from literary imagination--one of the reasons I'm very grateful for the graphics people in my area.
5. Draft: Start taking a SWAG (engineering term for "scientific wild-@$$ guess") at what you want to say. You've got the content, you've got the layout, now you just need to start doing the brick-and-mortar work of putting words together. Get the basic thoughts down first.
6. Polish: Your first draft is almost guaranteed to look and read nothing like the final product. This was a hard lesson for an English major to learn coming out of college, where I liked to think that the fire of raw inspiration would carry the day. The serious work isn't getting it down in one fell swoop, but getting it right. This is the point where you start trying to capture the "voice" of your customer and the tone you want to set for your audience. If it's an Important Thing, like something to do with legal or regulatory compliance, your tone is direct, serious, and no-kidding-this-has-to-be-done-or-you-go-to-jail. If it's introducing a new product or service, the tone should be enthusiastic ("See what we're doing" or "See what we're doing for you?!"). If it's something warm and fuzzy, like the annual Independence Day party, perhaps a little levity is called for. It also helps to know the personality or preferred style of your executive. If their behaviors or preferences aren't well known, you might have to ask.
7. Peer Review: Have another writer or, if none is available, your customer, review your best-guess, polished draft. Expect other ideas and revisions. Depending on whether it's the customer or a peer, you might or might not have more say about changes. If your peer or customer questions why you organized the information a particular way, be prepared to explain your thought process. This can go on for one or multiple cycles. Again, don't take this as the mark of a bad product or a reflection on your work. Requirements change for communication products as much as engineering products.
8. Finalize: This is where you tweak the minor stuff...missing punctuation, grammatical and other typos, and then turn things over to your graphics person(s) to go to print or online.

I probably could have stopped at step 6, but I've learned a lot about product improvement even toward the end of a development cycle, so it's worth considering the entire "life" of a document as you're creating it.

In the end, you should have a product--web site, presentation, letter, white paper, brochure, or other document--that accomplishes what your customer wanted in the first place. And yes, I do get paid to do this.