Why wikis won't kill technical writing

Many people have predicted that wikis will replace traditional help in the future. Ok, I can buy that.

But I've also heard that technical writers will surrender content control to SMEs and users, and will move into other roles such as merely editing wiki content, or switching to programming, training, etc.

Sorry. I just can't see that happening.

In the world of wikis, technical writers will still be kings of content. Here's why...


If you've ever read through wiki or forum discussions between users or SMEs, you're probably aware that unorganized information is not user friendly. A usable wiki must have an intuitive structure. Technical writers will likely fill that role.

Information architecture is one of our primary skills, and a technical writer or help author will have an existing knowledge of how to organize the documentation because of previous experience organizing help and print content.

Extensive cross-referencing will also require a technical writer. A user or SME may think to link to a related procedure, but it will be a technical writer who replaces that single link with a comprehensive set of cross references so that it is helpful to a wider number of users. In fact, the writer will likely reformat an existing set of related links taken directly from the help. Extensive cross referencing would be difficult to anyone without a big-picture view of the documentation.

Generating content

Will users write helpful troubleshooting content? And will SMEs be better equipped to verify that the content is accurate?


But will either bother to provide comprehensive documentation, such as a complete set of installation instructions or system requirements? How about an introduction to the product for new users?

Not likely.

A single user or SME won't usually have the time or inclination to do so. Users are more interested in answering task-related questions. (For tips on writing FAQs, see http://www.helpscribe.com/2008/01/9-tips-for-writing-better-faqs.html.) Developers have higher priorities, such as improving the product itself. SMEs may review content, or provide chunks of information related to their individual component of the product, but aren't likely to spend time writing comprehensive instructions or providing cohesion between their content and information from other SMEs.

Technical writers, on the other hand, are devoted to the documentation. They have the information-gathering skills to turn unrelated chunks of notes into something that won't leave readers scratching their heads.

Managing the documentation

The best wikis will be written by technical writers, with tactful references to user forums when appropriate. Reviews and conversations with SMEs will be delegated to the Discussion pages of the wiki. Technical writers will then finalize that information by moving it into the Guide section of the wiki, so that users don't have to wade through a meandering jargon-filled conversation that may or may not provide any useful information.

The Guide section of the wiki will be locked down to filter out noise. Login will be required. (For example, see the Blender wiki. New writers need to request editing privileges and work with an existing author, and new content is sandboxed.) A documentation team will still be necessary to manage the wiki, just as they managed the old help and print content.

In short, technical writers will be doing the same job we always have. We'll just be using a new tool that offers some very promising features. We'll have improved communication with both users and SMEs. Everyone wins.

Will technical writers delve into programming, training, usability, and other tasks? Sure. But we've always had to wear lots of hats, haven't we?

At the end of the day we'll still call ourselves technical writers.