I’ve discovered that I write more conversationally when I’m putting together a script for live training or a tutorial than when I’m writing help or other documentation.

Lately, when I’m writing for training, I’m thinking of actually having a conversation, of talking to a real person. When I write other documents, for some reason I’m not thinking this way. It’s a problem because my user assistance content probably comes out dry as a desert in summer. In addition to not being as conscious of users as I should, perhaps there are a couple of organizational factors affecting my mindset.

We have a culture of seriousness and of respect for authority. We deal with sometimes sensitive matters and personal data, things not to make light of. This makes it difficult to consider writing in anything but a serious tone, especially when I’m providing help for an application that supports serious business processes. If I were to release documentation with an informal or lighthearted tone for an application of that kind, it could be seen as insensitive and inappropriate. That’s not the reaction I want from someone I want to use and trust my documentation.

Further, many of us have developed a respect for our leadership for a number of reasons. Many of our sites and systems are built for use by these leaders. Though these leaders are normal people in a lot of ways, I would feel uncomfortable trying to hold a casual conversation with one I didn’t know well. Similarly, casual copy doesn’t seem to fit in applications built for their use because it’s hard to imagine talking in a casual way to a leader I highly respect.

This is not to say that no one in the organization ever smiles. In fact, I’ve never worked in a place with as many people with a sense of humor. Our managing director makes our department meetings more interesting by including some levity. However, part of our jobs is knowing when to be serious.

I realize there’s a difference between being conversational and being overly casual. But in writing technical content, it’s hard to find that balance. In my mind, writing something conversational often involves more words.

For example, a technical explanation could read like this:

Only system administrators can add agents in the application. For security purposes, agents’ user accounts automatically expire after 24 months if not manually renewed by an administrator. Agents must reapply for an account every 24 months.

And the more conversational version:

System administrators set up user accounts for agents. To satisfy the company’s security policies, agents’ accounts are set to expire after 24 months. To keep an active account, each agent needs to reapply for an account before the 24 months are up. A system administrator will respond to the request and renew the account for another 24 months.

To me, those two paragraphs say essentially the same thing, just in different words. No sentence in either paragraph exceeds 20 words. But in trying to convey the concepts discussed in the first paragraph more simply, I ended up with four sentences instead of three, 57 words instead of 36.

Perhaps that’s part of what makes a truly talented technical writer: one who can both write on a level the user understands and does it concisely. I’m still working on that.

Related posts (auto-generated):

  1. A Possible New Step in the Writing Process
  2. First Principles of Technical Writing
  3. Some Technical Writing Humor
  4. Could Technical Communication Be Entertaining?
  5. Preparing for the Technical Writing Profession, Part II