I’ve touched on research before, but it’s always a topic worth revisiting. As a technical writer, I’m constantly exposed to new topics, which require me to expand my field of knowledge. Occasionally I have to apply a system to what I do or invent a new system for a new field.

“Drinking from the fire hose” is usually the first step in any topic I have to learn. I look at the list of questions I have to answer and the issues I have to cover. If the topic is completely off the radar, I might be asking myself fundamental questions:

• What are the primary definitions/subtopics that I need to know?
• How does this idea/product function?
• How does this topic relate to information I already know?
• What are the other keywords associated with this topic?
• Once I understand the landscape, how do I organizemy topic?

Starting Points

I’m going to cause a lot of folks–especially university professors–to cringe, but I’m coming to appreciate Wikipedia.org as a first stop for research…not as a primary or even secondary listed source (unless your project invites informality). However, Wikipedia serves as a great starting place to get the big picture and basic definitions, especially on technical topics. Wikipedia becomes a problem on controversial or current topics because “the jury is still out” or because the Wikipedia judges have locked down the topic because too many conflicting opinions are flooding the wiki space.

Wikipedia has one saving grace: the references at the bottom of the page. Wikipedia entry writers must provide reputable sources for their content. Those are the places to go when you want more authoritative content.

Beyond Wikipedia, you’ve got your sources: textbooks, websites, subject matter experts, and so forth. You’ve got to absorb a lot of information, usually in a very short time.

Bringing Order to Chaos

Okay, so you’ve answered the basic questions (“What is it?” and “How do things fit?”). Your next task is to corral the topic into more manageable chunks. I’ve covered this subject elsewhere at the link cited above, but the primary think to remember about your topic is that what you write should be organized based on the nature of the topic itself. If you’re covering something that’s a physical object, it can be organized by its physical attributes or functions. If you’re covering a process, you can organize it by the order it which it happens or the functions from which it’s comprised.

Telling Your Story

When you start writing, another issue that’s important is having a “story line” in your head. I don’t mean turning a technical manual or research report into War and Peace. However, stories have a flow to them that people understand. They have a beginning, a middle, and an end. They have a message. They have characters (the users). They have settings.

Another thing that can help the writer of technical content can do is organize it by analogy from another field. Could an analogy from the human body or other aspect of nature be used to explain a business’s operating systems? Or, working backward, are there technological analogies that could be used to explain a biological process? This sort of analogy, if it’s common or familiar to your readers, can also help them understand your content.

It seems obvious, but your final writing product should mirror research process. You start with the basics and work down to the details in whatever fashion makes the most sense to you. If your research process is scattered or disordered, your final document can end up that way, too. (One caveat: I’m very process-oriented when I research, working from the big picture to the small. Not everyone works the same way, and the content can still come out with content that’s organized.)

Happy researching!