Return to Writing Information Pages

 

Tech Writers Need a Manifesto  

Product Lines

Information Pages

Services

Other Business

 

 

 

 

 

 

Today, when technology and technical products are flooding the world, good tech writers and good documentation are more important than ever--and that importance is growing every day. Yet, tech writers generally aren't understood, appreciated or fully utilized, even within their own companies.

Face it. Tech writers have a bad reputation.

I was actually introduced to someone at a party, who said, "You write computer manuals? I've always wanted to kill one you guys."

The problem is, for the most part, this reputation is undeserved.

Yes, a lot of documentation is bad. Useless, annoying and boring. But why? Is it because the tech writers can't write? Is it because they don't want to produce good work? Is it because they don't care?

Admittedly, sometimes it is the writer's fault, but most of the time, it's because of corporate culture.

In the high-tech world, the gizmo is god, the software is king. Documentation is the old-tech, ugly little sister. It doesn't break new ground. It's not what the people pay for. It's a necessary evil that has to be included in the package because the competition puts one in the package. Therefore, manuals are generally cranked out as quickly and cheaply as possible. Tech writers are brought onto projects at the very last second, given very little support, and very little time to produce a manual.

Getting information out of a development team to write a good manual can be like pulling teeth. They don't want to take the time away from the hardware or software to answer "useless" questions. And developers constantly add or change features without bothering to tell the tech writer, so the documentation is out-of-date before version 1.0 of the product ships.

Yes, there are a number of exceptions: companies that know the value of good documentation, and that spend the time and money to do it right. And so you don't think that this article is nothing but a sour grapes rant, I want to state that I spent nearly 10 years at a company that understood and appreciated documentation, and gave the writing group the freedom, finances and support to do a good job.( Of course, even within this very progressive company, there were constant "battles" for staff, for longer manuals, for increased COGs, for more testing, etc. But this is part of the process, part of the business, part of the politics.)

But the vast majority of companies just don't get it.

They don't understand that documentation is an important part of the product--a major element of the user interface. More than that, good documentation is good for the company. The manual is often the first impression the consumer has of the product--shouldn't it be a positive impression? And on the financial side, the cost of customer service and technical support is astronomical. A good manual and help system can eliminate thousands of phone calls from confused, frustrated customers.

In addition to corporate culture, something that keeps us from getting the support we need is the fact that so few customers have seen really great documentation. They don't know what is possible, what they deserve and what they should demand.

The final party to blame is: ourselves.

There are two aspects of tech writers: the writer/artist aspect, and the technician/engineer aspect. Neither of these aspects are generally enamored by or interested in mundane things like business, finance or office politics. But business, finance and office politics control the decisions that control our work.

What can we do about it? How can we change the way companies think of us and our potential? How can we get the time, finances and support to produce great documentation?

As I see it, we need to do two things:

1. Change our own mindset.

We need to stop thinking of ourselves as tech writers or manual writers--or even as writers--and start seeing ourselves in the bigger picture: we are communicators, we are teachers.

2. Educate ourselves and those around us.

  • We need to educate company management about our capabilities, about our value, about our potential to improve a company's bottom line.
  • We need to educate development teams about our potential contributions to the team, to communication within the team and between the team and the rest of the company, and to the product itself.
  • We need to educate the consumer about the excellent, useful, even entertaining documentation that they deserve, and about what they can do to help us help them.
  • We need to educate ourselves about the best and latest ways to present information, in manuals, in help systems and in the products themselves. And we need to educate ourselves in the business, politics and finance of products and documentation, so we can present our cases in ways that will make an impact on a management team that is primarily concerned with the bottom line.

To the end of accomplishing these goals, and improving the reputation, working conditions and work quality of tech writers, I propose a Tech Writers' Manifesto.

This manifesto will be a short document, ideally a single page, that simply states who we are, what we can do, what we will do. A mission statement for technical communicators.

I have put together a rough draft as a starting point, and invite all interested parties to comment and contribute. An online discussion forum for writers has been made available for exchange of information about this or any other topic of interest.

Click here for the rough draft of the Tech Writers' Manifesto.

 

 

Specials

We've got a few of our products that were slightly scuffed in shipping, or were paged through a few times at trade shows or seminars. Click here for great deals. 

 

Also see:

 

Unless stated otherwise, this page copyright UnTechnical Press. All rights reserved.
UnTechnical Press, 16410 Gibboney Lane, Grass Valley, CA 95949   530 271-7129    Fax: 530 271-7129

info@untechnicalpress.com   sales@untechnicalpress.com   education@untechnicalpress.com   webmaster@untechnicalpress.com