I’ve been working on a huge technical writing project for a client. They expect to start rolling some of my work out to their staff and partners between November 2010 and March 2011. They have thousands of pages of supporting documents that go back at least 4 years. So, for the next few months, I’m trying to make sense of it all while I turn it into something useful.
I’ve been swimming in a flood of paper: Reading, sorting, and mapping it out. And recently I was asked by three different people, “What’s your process of turning a great big pile of unsorted guidelines, case studies, and marketing documents into a comprehensive, user-friendly, step-by-step document that someone can follow?” I thought it might make an interesting blog post.
So here’s a generalized version of my technical writing process:
- One of the first things you need to do is figure out who the end user is going to be and what they are supposed to accomplish as a result of this project. From branch operations to CRM systems to selling a specific product, each technical writing project I’ve worked on had an end user who was supposed to achieve an end state. So find out what it is. It also helps to try and figure out what their motivations are (will they accept the changes or resist them?) because you can shape your work according to their level of alignment with the purposes of the content.
- Get a high level view of the project, review the business case, and review some of the material to get a feel for what you’re facing.
- Now here’s the secret ingredient and this step will make all the difference for you: Start mapping out an ideal future pathway or methodology that you will be writing to. These are the steps in the process that people will be taking to achieve the end goal. Each step in your work will probably be a major point in the step-by-step instructions you’re writing.
- Build out a similar “current” pathway so you can outline how the process is done today and can compare the two.
- Now start reading all of that reading material in-depth. Assign a code to each document and then look at your process map (in step 3) and see if you can find a place for the document on that map. If you can, great. If you can’t decide if it a good reference material. Chances are, if it can’t be tied to one of the steps on your process map and if it won’t make a good reference then it should be discarded.
- As you build your map, write in the names of people who can help or reference sites to obtain more information.
- Below each point, start fleshing out subpoints, steps, or tasks, and arrange them in order within each point.
By now, you should have a big piece of paper (or, more likely, a Word document or several pieces of paper taped together) that captures the information of the entire solution.
File those documents into some kind of order. Put the discards in a discard file (and keep them until the project is published). Put the rest of the documents into coded files that align with the steps in your process map.
And now you can start writing, interviewing, and continuing with research. Of course, all good technical writing is iterative and collaborative so expect to get back to earlier steps and make adjustments as necessary.
[Photo credit: epSos.de]