User guides and manuals are normally the last link in the chain when software is developed.

Once the product has been tested and passed though UAT, the application is forwarded to a technical author who documents all of its features.

Inevitably, it’s the last thing that gets done.

By this point, time and money is often limited. User help is very much at the end of the production line, and the resources available often reflect that. It can seem impossible to get the product documented properly without an overspend, and some developers are tempted to try and manage without an expensive user manual.

Many companies ask us if we can produce technical manuals within a relatively meagre budget. The answer is yes – with a few caveats.

Here are a few ways to reduce the cost of technical writing and get your project completed with the resources you have left.

Are You Using the Right Format?

When we think of a user guide, we normally think of a weighty paper document that emits a thwack when it’s deposited on a desk. Many end users still really like to have a large manual to refer to. But paper manuals are expensive to produce, and if they’re written in a regular word processing tool like Microsoft Word, maintenance can be extremely time consuming.

As technical writing software evolves, more options are open to us as technical writers. We can economise by creating webhelp, or producing help for smartphones and tablets. We can publish your help electronically on the web, give you an ebook to forward to clients, or create help in an online forum or wiki.

In short, get away from paper if your users are comfortable with that. It’s the easiest way to economise on production and updates. And employ a technical author who can single-source your help content in a professional tool (we use Madcap Flare, but there are others), simply to save time.

Are You Planning to Over-Document?

Consider the typical end user and ask yourself this: how much of your application do you really need to document?

In an ideal world, every application or app would have a fantastically informative user guide relaying the finer points of every function or screen. In reality, that’s very expensive. But more importantly than that, too much detail makes users feel overwhelmed. Overdo it and your manual gets filed away on a top shelf somewhere, next to that rarely-used phone directory.

When creating a user guide, it’s tempting to document every screen, every button, every outcome. And for some applications, that is a perfectly valid thing to do. Equally, a highly detailed technical manual may be overkill. The best way to assess your users’ needs is to survey them on your existing documentation: ask them how many times they’ve used the manual, whether the level of detail is suitable, whether they find it confusing and how many times they’ve contacted your technical support team after reading the help text. This should help you to decide whether you’re pitching it right.

Equally, you may need to increase the detail you’re giving people – so be prepared for the opposite outcome.

Will You Avoid Scope Creep?

User documentation evolves over time. So does software. When the two are being developed in parallel, it’s inevitable that there will be a shift in requirements over time.

When documenting, it’s important to define your needs at the start and stick to those needs.

The more stakeholders you’ve involved, the more likely it is that the requirements will grow over time. Ask your technical author to prepare a scope report, sign it off and use it as a blueprint to ensure you don’t overshoot the budget.

Also, the evolution of your software should interfere with the documentation as little as possible. Your developers need to be sensitive to the fact that someone is dipping in and out of the software, taking screenshots, writing process descriptions and documenting functionality. If a developer changes the colour scheme or alters the wording on the Submit button, it may not seem like a big deal to them. However, your technical author will probably recoil in horror.

How Will You Keep Your Document Up to Date?

Creating a manual can be a lengthy process, but documentation is never really finished. As your software evolves, your manual will need to evolve alongside it.

Consider the impact of maintaining your help files. Find out who does it, and how much time they spend on it. Ask yourself whether the software they use is adequate, and whether the documentation is really in sync with the product every time an update is released. (It should be.)

All too often, there’s no real process in place once the user guide is finished, and that makes inefficiency more likely. The person revising the documents might not have the software used to create them and may not use the conventions and language that a technical author is trained to use.

To keep costs down, it pays to be organised and consider document revisions in your release schedule and when processing change requests.

Employing a technical writer to process changes may seem like an extra expense you could do without. However, a specialised member of staff will be able to handle the task far more efficiently than someone who you’ve temporarily seconded into the role.

Economising on Help

Economising on user help isn’t necessarily a bad thing. We work with lots of small businesses and one-person development companies that simply can’t afford a detailed manual, but this forces them to think more creatively about the help they’re producing. A new approach can actually revitalise your help and make it more focused on the user and their needs. Smaller manuals are often less scary. They get used more, and they’re easier to manage.

But short manuals aren’t for everyone, and the only person that can judge the scope of your application is you – ideally with the help of a technical author like me or Mathew.

The most important thing is to have some help in your application. Don’t be tempted to lose the help text altogether. You’ll only wind up answering three times as many support calls in the long term, and your users will eventually ditch your software if they can’t get their questions answered quickly.

The following two tabs change content below.

Claire Broadley

Technical writer, blogger, and editor at Red Robot Media
Claire Broadley has been a technical author and web content writer at Red Robot since 2010. She contributes to dozens of websites, focusing on consumer technology, online privacy, digital marketing, and small business topics.
Share this:
Show Buttons
Hide Buttons