President’s Message:
What’s in a name?

by Debbie Kerr, President

While a rose by any other name may smell as sweet, a technical communicator by any other name may not convey what we really do.

Many of us use the title, “technical writer”, because it’s the only one that people seem to understand. At least with this title, people know that we write, but, unfortunately, they don’t seem to know what else we can do. The problem is that people focus on our writing skills and disregard many of our other skills.

Analyze this…

For example, the other day I asked a co-worker whether her group would need me to work on a project that I had worked on previously. She told me that they would need someone else, a Customer Analyst, who could identify gaps in processes and procedures. I was stunned.

After over 20 years of writing procedures, whether they were part of software manuals or part of policy and procedure manuals, I knew that I could do an analysis of processes and procedures, identify gaps, and recommend changes to those procedures. I had often found holes in processes when documenting functionality. In fact that was my job in several places I had worked previously; the problem was that they assumed because I didn’t have the correct title that I did not have the skills needed to perform the job.

Many people don’t seem to realize that 50 percent of technical communication involves analysis of some kind. If you are documenting software, you end up analyzing the design and layout to look for inconsistencies, logic flaws, and process improvements. Your analysis may also help you to find ways to explain difficult concepts and functionality. When someone tells you to document something, as a technical communicator, they might as well be telling you to analyze this. To me, they mean the same thing. Maybe a good compromise for a title is Technical Writer/Analyst.

Getting a little testy

Another skill you may discover, especially if you are documenting software, is you are a tester. While familiarizing yourself with the software you are documenting, you may find bugs and interface changes that, if fixed, will improve the user experience. Once, I was reporting so many problems that they asked me to take a break for two weeks so that the developer could test the product himself and make fixes before I looked at the product again. Two weeks later, I started testing again, and I was still finding the same number of errors. It seems that a technical communicator can definitely be testy, in more ways than one. The logic and analytical skills associated with being a technical communicator helps to pinpoint problems that may be accidentally overlooked.

Since testing ultimately improves the customer experience, involves some analysis, and results in better writing, maybe a good title is Technical Writer/Analyst/Tester.

Looking good is half the battle

You can create a poster with a great message, but if it doesn’t get anyone’s attention, no one notices it. Unfortunately, the same is true for what you create as a technical communicator. It’s hard enough to get a user to look at the documentation, but if it does not look professional, the chances of a user looking at a manual or help file decreases even further. The professionalism of the presentation also affects the user’s perception of the content. Poor presentation of material means the user will not trust the content. In the software industry, this means the call to the help desk that you hoped to eliminate happens anyway.

Design skills are not limited to paper. If you have ever tried to find information on a website or use new software, you can appreciate that good design and navigation determine whether you use the site or the software again. Since you have represented the users’ needs for so long, you are able to make design decisions that are also good usability decisions. You have learned and developed a “gut instinct” for what works and doesn’t work when trying to communicate to users. You know what information to put where, and you know how to collect that information from users so that you can design products and websites to best suit those users’ needs.

Maybe Technical Writer/Analyst/Tester/Designer is the title we go with?

Getting down to basics

Part of the problem with deciding on an effective job title is that we fulfill such a wide range of roles. While some of us are writers, others communicate through roles as editors, illustrators, media specialists, and web designers. However, with all our differences, we have some commonality when it comes to the basic tasks that we perform. As technical communicators, we:

• Research to obtain the required information, whether it be interviewing subject matter experts (SMEs) or reading existing information,
• Analyze the collected data and organize it until it is in a logical order, and
• Simplify complex information and present it in a clear and concise way.

This is really the lowest common denominator. You’ll notice that I don’t say how you present the simplified information. That’s where you get into the different media that you might use to communicate the limitless possibilities.

The other basic is the entire reason for doing all this is to help a user. This is why I am proposing User Advocate as a possible job title. I figure that with all the comments I have made over the years to simplify the user interface, to simplify concepts and terminology, to simplify documentation, then I have definitely been representing each user’s needs.

Accepting nothing at face value

It’s not just others who have a fixed way of looking at us; sometimes we are our own worst enemy. Our own single-mindedness prevents us from seeing how a course or presentation can apply to us. We think of ourselves a certain way, and we fail to see how a meeting or course could possibly apply to us. We have to see what’s in it for us.

One example is our most recent general meeting on card sorting. A subject of Card Sorting might have made you ask yourself how recipe cards could possibly help you communicate more clearly. If you came to the general meeting, you would have seen how card sorting could be used to determine the best way to set up a website’s navigation. You would have learned about using them to get user feedback. You would have also seen that this same technique could be used for software documentation or software design. Even the small sample of card sorting that we tried during the meeting showed how different types of people might sort the same types of cards. It was an eye-opening experience that demonstrated how a small group of people could sort the same topics in so many different ways.

This meeting was definitely applicable to anyone in the communication field regardless of what media you use to communicate.

In Conclusion

The scope and variety of a technical communicator’s role make it difficult to come up with a title to accurately describe what we do. However, the large range of skills that are wrapped up into one role make it more efficient to hire one of us. I would definitely worry less about coming up with a good title and point out to any potential employer that hiring a technical communicator by any kind of name is truly a “sweet” deal.

About Debbie Kerr (President)

In the 20 years that Debbie has been writing documentation, she has worked in a variety of industries: government, retail, software, and insurance. She is currently employed at The Economical Insurance Group in Waterloo, where she has stepped out of her traditional role of writing user guides and help files, and now writes a variety of specifications.

Debbie has been a member of the STC since 1994 and has been a council member for many years. Most recently she was The Quill editor for two years.