We’ve produced, edited and updated a number of software user guides in Red Robot Media’s history. Technical writing is one of our key services, and the majority of the work we do – apart from blogging – is user documentation work.

You might be surprised to learn that we try to encourage clients to trim down requirements, and we never suggest the production of documents that we think aren’t needed.

Here are a few of our other golden rules for technical writing assignments.

1. Never use Word

We use Madcap Flare to single-source technical writing projects. Why? It’s the best tool out there (and I’m pretty well versed in Adobe Robohelp, so I’m fairly sure I’m right here). It saves clients money when we use Madcap Flare because we can output to any format, subject to creating the right templates, and we can re-use projects when new versions of the software are due to be released.

Some freelance technical writers choose not to invest in Madcap Flare, but we think this is a poor decision. Word has a lot of fantastic features, but it’s not a technical writing tool. It’s better to invest time in properly structuring a manual and inserting the right features (glossaries, pop-up help etc) than trying to wrestle with the quirks Word sometimes exhibits. (I wrote a blog about them here).

We bought Madcap Flare with maintenance and it was probably the best decision we ever made as a technical writing company.

Of course, we can output documents to Word format – we just don’t actually write them in Word.

2. Save your money: less is more

The days of massive product manuals, at least in the consumer electronics industry, are long gone. Why? Because people don’t read them. When you last bought a smartphone, what did you do first: read the manual carefully, or plug in the device and switch it on? Can you honestly say you’ve ever consulted the manual for an electrical item in your home, apart from perhaps your VCR?

There’s still a place for large manuals when writing software documentation, and some companies do still produce paper documents for consumer electronics as well. In general, anything that needs to be ‘learned’ needs a large document; software (and also SaaS) falls into that category.

But when you buy a product from Apple – or an Amazon Kindle – you’ll get little more than a pamphlet showing you how to plug it in. Apple and Amazon are smart. They don’t waste money and resources printing things people don’t want.

When getting a quote for a technical writing project, consider realistically what your clients need in terms of help documentation. If they really do need a 200-page handbook, we’ll gladly write one for you – no problem. But often, you barely need more than a Quick Start guide, particularly for intuitive services. A series of small documents can also be friendlier and less daunting than one large one.

In short: We don’t like charging people money to write things their clients will never use.

3. Technical writers should have training

Ask your chosen freelance technical writer if they’ve ever undertaken any training specifically for the job. I don’t mean reading blogs or getting advice on Quora. I mean actually paying for a technical writing course. These courses are invaluable. We’ve both done them, and will continue to do them.

OK, training isn’t cheap, and as a small company, we did have to balance the books for these courses. But hiring a trained technical writer is a sensible investment if you want usable documentation that’s backed up by solid evidence of writing styles that really work. If someone has ‘decided’ to become a technical writer but has nothing on paper to back it up, find someone else to do the job.

4. IT support experience is a must

Both of us at Red Robot Media developed an interest in technical authoring because we’d worked on IT service desks. Through experience and ITIL training I realised that many of the support calls users place are actually help documents begging to be written. A cycle of frustrated callers with the same questions is awful for morale on a help desk, and it doesn’t do the users any favours either. Technical writers have a much better understanding of user experience if they’ve been on the front line, as we have.

5. Pricing should be realistic in technical writing

I’ve been asked to write technical documentation for as little as £3 per hour. Needless to say I turned down the work. In order to pay for the software and training we need to do the job right, we charge enough to cover our costs – just as we would in any other job.

Don’t assume a technical writer charging low prices will write the same document as someone who charges the going rate. We’re probably a little cheaper than our competitors, to be fair, but that’s mainly because we work really hard to keep our overheads down and we pass on those savings to the companies we work with.

Pay for quality documentation and your users will be happy. Support calls will go down, so your support department will be happy. Brand awareness will increase as people rave about the quality of your help material.

Carefully considering document formats, innovative help outputs, the right length and detail and the intended audience will help our technical writers to pitch the material at the right level, avoiding alienation of those who may otherwise find it too simple (or too complex).

Got a project for us? Got any questions about our technical writing services? Drop us a line now.



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