Plainly Speaking: Be the User’s Mentor, Not the Company’s Mouthpiece

Today is the second post from our newest regular guest blogger, Karen Field Carroll. Karen sent us a post two months ago on how technical communicators can (and should) support the Plain Regulations Act, and we asked her if she wanted to blog regularly on the topic of plain language. She’ll be posting once a month under the general title of “Plainly Speaking.”

Plain language—that is, clear, readable text and document structure—can improve any document we create in technical communication. (And by “document,” I mean documentation in any form–a tutorial, a user guide, an online help topic, a Wiki, and so on.) Using the plain language style requires that the technical communicator:

• Analyze the user and write to that audience, focusing on the user’s goal rather than the product’s features or interface.
• Choose the appropriate medium for the user (online help vs. tutorial, for example).
• Organize the document’s content to meet the user’s needs.
• Use word choice and sentence structures that convey the message without distracting the user from the message.
• Lay out the document so that it is visually inviting and easy to navigate.

Most plain language style guides I’ve unearthed can teach you these skills to some degree, but none explores them as they apply to technical communication.

Technical communication brings a new dimension to plain language. Why? Because often users aren’t just reading a document; they’re interacting with a product. The product is the reason the document exists. (That’s the difference between plain language in technical communication and plain language in areas such as finance, medicine, or government: These latter genres, although no doubt afflicted with their own challenges, don’t have an interloper like a product to distract the writer and yank the whole document off the rails.)

But even if the product is the reason for the document, it shouldn’t be the focus of it. Technical communicators—and I include myself here—struggle with this. We see an interface, and so we write about it. We write about the product, instead of for the user. The product ends up driving the document’s organization, wording, and syntax. (This is true even in so-called “task-oriented writing” if the writer lets the product’s interface determine the order in which the tasks appear in her documentation.)

In sum, we forget that to the user, the product is only a tool.

Which brings me to the first principle in developing plain-language documentation: Analyze the user and write to that audience, focusing on the user’s goal rather than the product’s features or interface.

Consider this sentence: Mike wants to use TaxTime to do his tax return.

What’s Mike’s goal? (Look at the object of the verb “wants.”) To use TaxTime, right? Nope. That’s the company’s goal: The company that makes TaxTime wants Mike to use TaxTime to do his tax return.

How about this: Mike wants to do his tax return.

Now, do you really think Mike wants to do his tax return? That he got up on one beautiful Saturday morning in late March and said, “Wow! I can’t wait to do my tax return today”? I doubt it.

One more try:

Mike wants his tax return.

Bingo. Specifically, Mike wants his tax return completed, signed, and filed electronically, if possible. For whatever reason, Mike has decided to buy and use TaxTime to get his tax return done. But the product is only the means to an end.

What I’ve just shown you are the differences among the user’s goal, the user’s tool, and the company’s agenda.

Enter the skilled plain-language technical communicator. You can separate the wheat (the user’s goal) from the chaff (the product and the company that sells it). You can build the document’s structure around the user’s goal. When you do that, when you figure out how to be the user’s mentor instead of the company’s mouthpiece, your documentation will begin to resonate with plain language. Also, your users will love you.

I’ve written at length about the method I’ve developed to create such documentation on my blog.

Next month: Some guidelines on writing plain-language text in a product-driven universe.

Karen Field Carroll is a senior technical writer, author, and plain language advocate. She and her husband live in Arizona with their German shepherd, Gunther, and their cat, Callie. Visit her blog at http://www.write2help.com.