The seven harsh realities of technical writing

With props and apologies to Sonia Simone over at Copyblogger, from whom I totally stole the idea and foundation for this article, here is my list of the top seven harsh realities of technical communications.

Sonia’s article, The 7 Harsh Realities of Social Media Marketing, looks at the “not-so-kumbaya” aspects of marketing using social media. As I was reading, it struck me again how similar marketing communications and technical communications can be. And I realized that the harsh realities in Sonia’s article have corresponding realities in tech comms. Unlike Sonia, I can’t think of a single kumbaya aspect of tech comms though.

Harsh Reality #1: No one is reading your blog
The tech comms correlation: Nobody wants to read your manual

Your customers (don’t call them users all the time, you’ll forget where your salary comes from) DO NOT want to read your manual, help, PDF, wiki, support website, or wiki. They just want to use the product they bought from your company, preferably with no learning curve or “unexpected operation”.

And your customers really don’t want to read your “About this manual” section. Sure you have a solid, logical scheme for bolding command names, italicizing menu choices, bolding and italicizing soft-key functions, but… Nobody cares.

Harsh Reality #2: You’ve got to give (some of) your best stuff away
The tech comms correlation: You’ve got to give all of your technical communications away

Make your manual, help, and so on available for free. Don’t hide it behind a pay wall or registered-user section of your web site. You don’t need to protect it; your competitors already know everything about your product. If you hide your user documentation, you are just making hard on your users customers.

Harsh Reality #3: It will eat your life (if you let it)
The tech comms correlation: Learn to let go of perfection

In social media marketing you worry that if you log off, you will miss a comment, blog post, or tweet. In technical communications, many writers worry that they have missed a style tag, an Oxford comma, a split infinitive. Let it go. Do your best with the schedule you have and your documentation will be good enough. If it’s not, your customers will tell you.

Harsh Reality #4: Social media hates selling
The tech comms correlation: Don’t market in your manuals

By the time your customers crack open your configuration guide they have already been sold on your product. That’s how they became customers, right? Your documentation should show them the best way to swing the hammer, not go on and on about how cool pounding nails is.

Harsh Reality #5: What they say is a million times more important than what you say
The tech comms correlation: The same!

What your customers say about your documentation and about your product is just as important as what you have to say about it. If you customers say it’s hard to find anything in your quick reference guide, fix it. If your customers say it’s too hard to power on the unit, rewrite the Getting Started section.

Harsh Reality #6: A blog is not a marketing plan
The tech comms correlation: A manual is not a functional spec (and vice-versa)

It is tempting — oh, so tempting — to “repurpose” the design document or functional spec to create the user documentation. Don’t do it! Your customers deserve more. A functional spec may have a lot of great information in it, but its audience is different. It’s purpose is different. Your customers need information that is designed to meet their needs, not the needs of the development team.

Harsh Reality #7: You don’t get to opt out
The tech comms correlation: Somebody’s got to write this stuff

Social media and collaborative technologies may have their place in technical communications, but your organization still needs a technical communicator to plan, develop, and maintain your user docs. You plan you products; why would your documentation require less? Even wiki-based documentation requires a moderator and manager. Useful documentation needs the strategy and experience that technical writer provides.