Can Others Do Your Job?

by Tom Johnson on Apr 23, 2009
categories: technical-writing

John from Delaware, who has a job in technical support, asked my advice about whether he should become a technical writer. He expressed some concern about the field, explaining that since almost everyone can write, the skill of technical writing must be decreasing in value. For example, technical writing can be easily outsourced. In an economy of doing more with less, is it really a good idea to base your career in a skill that is increasingly done by others who are not technical writers?

A graphical representation of John's question might look like this:

Even though an engineer may be able to write well, there's a lot of supporting tasks one must do prior to writing so that the content will be worthwhile. It's not just composing a graceful e-mail and clicking send. You have to metaphorically build a foundation and erect the walls before you can finally put the roof (the writing) on.

To be more specific, Shanghai Tech Writer says she spends just 10% of her time actually writing. This disproportion surprises most people. If only 10% of your time is taken up with writing, what happens to the other 90%? Your other time is consumed with the following:

• Designing the look and feel of the manuals
• Designing the look and feel of the online help
• Single sourcing the content to produce both online help and manuals from one source
• Finding out what tasks you should document, based on the tasks users perform
• Conditionalizing text for role-based guides
• Researching the user's terminology, environment, and behavior
• Anticipating pain points and user questions in the application
• Understanding how the application works (and when and how it doesn't work)
• Organizing all the information you collect
• Discovering non-obvious application information from subject matter experts
• Fixing dreadful wording on the user interface and pointing out bugs or quirks
• Figuring out how to work advanced page layout and help authoring tools
• Making sure what you've written is accurate and up to date
• Making sure your content conforms to your company's style
• Learning or defining your company's style
• Creating diagrams and illustrations to communicate complex concepts
• Manipulating screenshots to be the correct dimensions, proportion, and file type for your help
• Doctoring screenshots to hide sensitive data and overlaying generic information
• Getting business and subject matter experts to review what you've written
• Attending project, department, and team meetings to stay updated about the application

Sometime during all of this, you actually get a few minutes to write the help text.

It takes 90% of your time to do all of these other tasks. These tasks are necessary for your writing to be relevant, accurate, attractive, organized, and so on. For example, unless you know your help authoring tool and company style and how the application is supposed to work, you can't write intelligently about it. Unless someone has time to do an extra job -- namely all the tasks in the bullets listed above -- most likely he or she won't be writing help content that approximates the quality of your own.

You may find someone willing to pitch in 10% of his or her time to do some technical writing, but not someone willing and able to complete the other 90% while also doing his or her regular job. Technical writing is a time commitment that takes nearly all your time to do it well.

Beyond time, though, explaining some technical concepts does require above-average literary skill. If the product you're documenting is complicated (for example, if you're trying to explain how a storage array functions for a non-engineer), it will require exceptional writing skills to communicate it clearly.

Not everyone possesses these skills, and the majority of writing from engineers I've seen reinforces this point. Being clear can require you to supplement your explanations with visual diagrams; it requires you to simplify your sentences, dumb-down your vocabulary, and spin the topic so it makes sense from the reader's point of view. Few people have the skill and patience for this.

Finally, many non-technical writers doing technical writing have illusions about the standards for help. The technical writing profession has been black-eyed by all the less-than-literate developers attempting to write help, which then appears to lower the standard for help content overall. User manuals have an incontrovertibly infamous reputation for sucking. As such, it shouldn't come as much surprise to find engineers or interns who feel confident they can at least match, if not do better than, the last user manual they read.

Reversing that assumption is nearly possible. Even half-way decent manuals still fail. Overall, help just needs to be better -- it needs to be more user friendly, more accurate, more relevant, and more convenient. It needs to be context-sensitive, full of visual illustrations, broken down into simple steps, accompanied by video tutorials, and more. If help were at the standard it should be, you wouldn't find so many people convinced that they can create help content.

To conclude, don't let the idea that “anyone can write help” deter you from the profession. Almost no one has time to write help while fulfilling his or her regular responsibilities. If people do have time, they often lack the talent to communicate clearly. And if they feel they have talent, show them an example of good help (rather than their VCR manual), and let them compare.