Over the last few months, the User Education Team has developed a content model and a supporting style guide. Our evaluation of various documentation authoring tools a few months ago resulted in our choosing Author-it—a tool none of us was familiar with.

In our discussions about our content model, or how our information is structured, sometimes we kept drifting into talking about what Author-it would allow us to do. It was an easy line to cross. The way you approach reuse and other considerations can change based on what tool you use.

But overall, the optimal way to structure information isn’t dependent on a tool. That’s probably why our team lead kept steering us away from thinking about whether aspects of our authoring approach and information architecture would be supported in Author-it. There were parts of our discussions that blurred the lines—we would sound like we were talking about the tool, but we really weren’t.

Such discussions highlight what I’ll refer to as the core component of technical communication.

That component is the heart of the term technical communication—that is, communication.

The secondary part of that term, technical, refers to the subject matter we are communicating about. But it could also refer to the method we choose to author, organize, and deliver the content, which these days rests in technology.

Technology changes. Communication channels and content delivery mechanisms change. We have Author-it today, but something more fitting for our organization and our needs may come along in a few years. DITA has spread through much of the tech comm space, but who’s to say something more effective won’t come along in the future, or that DITA won’t evolve (see what I did there) into something better?

Yes, the technology changes, but the core principles of communication don’t.

Varying definitions of communication exist. Some say that a message has to only be released from its source to be communication. Others say it has to be understood. I’m more in the second camp, and I would add that the message needs to be understood the way the originator intends. Otherwise, have you really gotten the message across? Has communication really occurred?

That’s why I’m not talking about “good communication.” It’s communication, period. Or it’s gobbledygook that doesn’t do the job.

I admit that the recipient of the message has to put at least a little effort into understanding the message. Those mental gears have to turn a notch. But communicators can make that effort as small as possible by doing what we do best: communicating.

What makes communication happen?

  • Clarity. The message is free—or as free as possible—from interference caused by indirectness and jargon. It’s phrased in simple terms.
  • Timeliness. The message comes when it’s appropriate. The recipient can make use of the information right then.
  • Relatability. I could also call this “connectability.” The recipient can connect the information to what’s already in his head. He can relate it with his prior experience.

It doesn’t matter what tool you get excited about; in the end, it’s just that. A tool. It’s a means by which to get a job done. My audience probably doesn’t care about my tool. In the end, what they care about is the clarity, timeliness, and relatability of my message. They care about accomplishing their goals.

Image credit: renjith krishnan | FreeDigitalPhotos.net

Related posts (auto-generated):

  1. Test Cases: More Like Technical Communication Than You Thought
  2. The Importance of Communication Skills over Technical Skills
  3. Could Technical Communication Be Entertaining?
  4. Technical Communication: The QA of Product Design
  5. Technical Communication Can Require Heavy Duty Hardware