How do you pick the right technical writing software?

From our recent workflow studies here at my company, we have seen that technical writers actually spend 40% of their time and effort working with their tools and 60% creating content using these very same tools. When an organization picks a writing tool, it is very typical for the organization to evaluate writing tools on a list of features. But the reality is that a writer's workflow is the true determinant of the features of a writing tool that will matter most to that writer.

Content architecture drives tool selection

When documentation is single-sourced or not (i.e. it is a guide or a set of internal procedures), there are certain features of the writing tool that will be more important to you than others.

Also important is the lifecycle of the information that you are publishing. Does the information published by a document remain generally constant, or does it change from time to time. A document published as static information is best written with a tool that supports the straightforward and easy publication of information in the form of static information. A document that is published and then frequently updated by a number of people would benefit from a number of features that support the versioning and collaborative editing of such information.

A writing tool is perfectly fine for individual writing projects, but for projects that are part of a workflow that already uses many tools, the writing tool must also integrate with these tools.

Scale and complexity considerations

One additional point about the number of writers on a team is that the number of writers does not scale in a strictly proportional fashion when it comes to determining features of a writing tool. For example, five writers working together would require more than five licenses, they would also need a writing tool that supports different permission types (e.g. Editor, Author, Administrator), supports different workflows for review (e.g. line by line, section by section, etc.), and that has robust features for handling and resolving conflicts between writers working on the same set of documents.

Document complexity matters more than document count.

Workflow integration and adoption barriers

The best writing tool with the best features is useless to you if your team does not use the tool. So, the key to successful implementation of any writing tool is how closely the tool follows the workflow of your team today. Writing tools that require you to change your workflow can take weeks to train your writers on and can result in your writers being less productive than they are today.

It is impossible to predict exactly how long it will take to get your content to work in a legacy tool or in a new one as expected. (As always, there is more work than one thinks when looking at a vendor's demo). The writer's time spent to get content to work in the new system is a key measure. Such time spent is usually considered to be temporary, but it quickly adds up to several weeks or even to several months of lost productivity of a team of writers. They will get back to full speed as soon as they finish getting the content to work in the new system.

Most technical writing software increases the writer's cognitive load (i.e. the amount of effort needed to write) and takes the writer away from writing and from checking the accuracy of the written material. As a result, the simplest tool should be chosen in order to keep the amount of time required to learn to use it to a minimum.

Testing with real content

Most vendor demos will use very clean (and simple) examples of documents to try and illustrate the main capabilities of the tool. But your writing will not be that clean and simple, so test your writing tool with your "real" documents: import them, edit them, and see how they generate the different outputs that you require.

As you test the different tools, pay close attention to how the writing tool performs as the volume and size of the writing increases. It is common for a writing tool to process well a few samples of writing, but then be unable to handle the rest of the writer's documentation library. To get a true sense of how a writing tool will perform for you and your team, test it with a sample set of documents of typical sizes and in typical quantities.

Cost structures and hidden expenses

There are often many additional costs associated with software that go beyond the cost of the license. These might include the cost of training the writer to use the software as well as the time required to implement the software into the writer's current workflow. In addition, the writer will also need to consider the cost of ongoing support for the software. These costs can be as much as the cost of the software or in some cases even more. Thus, the writer must consider the total cost of ownership (TCO) of the software in addition to the cost of the software.

A subscription-based solution seems to be reasonable in the beginning. However, a stable technical writing team might not use all the features of a solution on a regular basis, which are then updated by the vendor from time to time. In contrast to the described solution, a perpetual license for a stable solution of a writer has a higher initial cost for the software. However, the writer can decide when to upgrade to a newer version and to use additional features instead of absorbing annual increases to the cost of a solution that is not needed by the writer.

When evaluating technical writing software, don't forget to calculate the costs to exit from the software as well. In other words, how difficult it is to export your content out of the tool. Some writing tools lock their customers into vendors for long periods of time.

Making the final decision

The best way to determine if a certain tool is right for your team is to run a pilot project with 2-3 products of interest. Use real projects and have the members of your team test the features and use the writing tools within the pilot project to uncover the good and the bad of each tool. The tool that your writers want to use is far more important than the tool that your manager wants you to use.

It is extremely important for us that writers accept to work with the new tool. Therefore, if writers reject to work with the new tool, then it will not matter how much more the new tool has than the current tool, the new tool will not help us to reach our goals.

Timing is everything when introducing a new technical writing tool to an organization. Avoid introducing a new tool in the middle of a production cycle, or in the middle of another change in the organization. It will take the undivided attention of the writers and the support staff to get the tool to be accepted and for it to become a part of the workflow of the writers.

The best tool is one that disappears into your workflow.