Putting the Pieces Together: Own Your Domain

Communication is receiver-oriented, and to realize that is a step toward communicating effectively. As people, we constantly communicate with those around us - verbally and non-verbally - so it's necessary to maintain audience awareness as we interact. As technical writers, we are actually technical communicators, so similarly it's important to determine how best to present our content as we write. To do that, we first must understand the receiver.

Domain knowledge, or knowledge about the content area for which a piece of software is being designed, is a technical writing necessity. Technical skill and knowing how to use tools such as Adobe FrameMaker or SnagIt are just one piece of the puzzle. These technical skills, which we utilize to create our content, must be paired with domain knowledge to provide a complete and effective piece of documentation.

Some argue that industry knowledge can be more important than technical know-how (see myth number four of 14 Widespread Myths about Technical Writing). The basic claim is that if the proficiency isn't already there, a technical writer is sort of expected to be able to pick up on how to use content management tools rather quickly. However, if the domain knowledge isn't already there, to learn an industry (the technical writer's audience) to substantial depth would take much longer (reiterated in a post by Doug Davis). That is to say, it's more difficult to gain knowledge about the subject for which you write than it is to learn how to use the tools for documentation.

To place a personal example on the subject, I became a technical writer - as a novice in the field - about a year and a half ago. The technologies and tools our department uses for content management were new to me, but I was able to learn how to use them fairly quickly. The part I struggled with most, and am still honing every day, was developing the knowledge about the subjects and audience for which I write. I have gathered plenty of helpful advice, tips, and mentoring from my peers, but it was recently that I had one of my most valuable experiences yet.

I was lucky enough to participate in a client visit, in which a group of employees went on-site with real software consumers in our market. We interviewed staff members of different roles and positions, observed employees as they performed daily tasks, paying attention to their needs and how their current software does or does not accommodate those needs, and asked questions to further learn their business processes. Watching users, of every level of the organizational structure, really shed a light on who exactly I was writing for - what kind of person she/he is, what sort of tasks they perform most frequently, and what their end-goal is each time they use a feature in our software. Since being concise in our writing is key, this knowledge is highly valuable when determining what should be included in our documentation.

Through operational knowledge of a given subject or domain, you can more easily identify problem areas, or areas in which more attention should be given. If you know, or even more than that, understand your audience's goals and needs, you can build your content accordingly to add as much value as possible.