Inside the Board: With Michael Hughes

Last Monday we brought you the first Prez Dispenser from STC President Cindy Currie. That will be a monthly feature on STC’s Notebook, as will be postings from STC Executive Director Susan Burton (first one scheduled for next Monday). Alternating between the two of them will be a look “Inside the Board” from members of the STC Board of Directors on various topics of interest. Note: The thoughts expressed in this post are not the official opinion of the Society for Technical Communication or its Board of Directors, but rather only of the individual.

Toward a unified definition of “technical communicator”

It’s bad enough that I periodically go through my own identity crises; it seems I’ve chosen a profession that collectively does the same.

I’ve been associated with our committees working on the Body of Knowledge and with certification, and on both of those committees we have had to wrestle with the question, “What is it that technical communicators do?” What are those common attributes that equate medical writers, software documentation specialists, and all the other variations of our profession? While working with the Body of Knowledge task force in its early days I heard the question asked this way: “What makes a technical communicator different from an engineer who writes well?” Essentially, why would you hire the former if you already had the latter? Steve Jong, head of the Certification Task Force, talks about a unified theory of technical communication.

I think this is a survival level question for each of us as professionals and all of us as a profession.

So, I’d like to use my fifteen minutes of fame this month to pose my perspective of what it is we do that links us all.

Essentially, technical communicators do the following: 

1. User Analysis. Define the users of the documentation and analyze the tasks that the documentation must support.
2. Document Design. Plan documentation deliverables to support those tasks. Design the organization, presentation, and technical architecture (where appropriate) for each deliverable.
3. Project Management. Plan the documentation schedule and monitor project process against that schedule.
4. Content creation. Create new content or modify existing content that tells the audience something useful and actionable.
5. Delivery. Build appropriate outputs, such as Help, web pages, manuals, and training, and promote those builds to the appropriate distribution channels.
6. Quality Assurance. Assess documentation for accuracy, adequacy, accessibility, and usability.

Sometimes we spend a lot of time on each, sometimes not so much. And yes, we sometimes skip some altogether. But if you were to poll anyone who has been in the profession for any significant length of time, I’ll bet they’ve done all of these at some point.

Although other professions might do these as well, I think that technical communicators have unique requirements in each that differentiate us as a profession. Our user analysis, for example, typically looks for information gaps that impede user performance or success. Similarly, our quality assurance is communication centric: are words spelled correctly, can sight-impaired users access the information in this Help topic, do the users make sense of this explanation in a way that moves them toward successfully meeting their goals?

I also think that everything we do that matters professionally can be categorized into one of these buckets. Even sub-skills like working well on teams have value only in the context of “to what purpose,” for example, to author collaboratively or to derive a team consensus around the user profile?

If we are going to move forward as a profession, we need to focus on our sameness for awhile, not our diversity. We need to periodically reaffirm that we are one profession.