Communication Arts

I specialise in information — how to organise it, how best to present it to different audiences and in different media, and of course, how to write clear, punchy instructions to help people understand the things they need to know.

I specialise in software user and training guides, procedures and process manuals, but also write corporate newsletters, technical articles, flyers and brochures. Today, most clients want the finished product as electronic copy (usually Acrobat PDF files or web pages), but I can also arrange for typesetting, printing and binding etc.

If you need any information analysed, processed or presented, just ask. If I can’t do it myself, I may well be able to advise you how to, and who can, do the job.

Here are more details of the main areas where I can help people with writing and publishing their information in an effective and appropriate way:

Software manuals, training guides and user guides

I trained as a software technical author with ICL (now Fujitsu Services), and have over 30 year’s experience of writing user manuals for all levels of user, technical specifications, training guides and tutorials. From first outlines to the finished text, or any stages in between, I can help.

Process and procedure documentation

With extensive experience in pharmaceutical, healthcare and general business environments, I can turn my hand to capturing your business and technical procedures and processes in easy-to-read, accessible handbooks. (I have specific experience in processes for clinical trial data capture and management, clinical decision support, programme office and document production.)

Writing for the web

I can design and write web pages for many purposes, and can also advise on processes for publishing and maintaining information, once it is on the web.

Copy editing

If you have a document written by many different contributors, or which needs polishing, I can edit the text so it reads consistently, is formatted properly, conforms to any standards, is properly indexed and so on.

Jobs like this often require “quick and dirty” editing — although the perfectionist approach is admirable, it is often out of the question for time or budget reasons. Although it may seem contrary to common sense, you need a real expert to do this — being able to do “the best job in the time” is a skill that only comes with experience.

I can write to your own corporate house style, or propose a suitable approach and design for an individual project, perhaps providing custom templates to support your own staff.

Publication

If you want printed manuals, I can help you find a printer and manage the production.

Copywriting and desktop publishing

As well as full-blown projects, I am happy to undertake small-scale jobs: newsletters, flyers, brochures, leaflets etc. Whether you need a few black and white copies of your latest price list, a programme for an event, or a full-colour newsletter to announce something to your company, I can do it.

After reading for a degree in Geology (BSc first class Honours from the University of Wales, Swansea) and some short-term programming for BP, I was trained as a technical author by ICL, where I worked for six years producing all kinds of software user manuals and procedural documentation. (At the time, ICL was generally acknowledged to offer one of the best industrial training schemes in the UK, and provided well-trained authors for many companies in the Thames Valley. It is now part of Fujitsu.)

I went freelance in 1985, and have worked for many clients including The Dorset Safety Camera Partnership, The Cauldron, gradwell dot com, Boehringer Ingelheim in the UK, Germany and USA, Orange Personal Communications, Somerset County Council, SFGL (a French software house specialising in CASE technology) and as an associate of Parity TMS, for various government, police and commercial and financial organisations. More recently, I’ve specialised in helping local small businesses, including Lyme Bay Arts, Bridport Cottages, Uplyme Parish Council and East Coker Neighbourhood Plan Groups.

I analyse, design and write all kinds of information — for print, online documents and web sites, especially in the pharmaceutical, healthcare, tourism and office procedural markets. I have had formal training in Information Mapping®; a structured technique for effective communication.

I specialise in documenting software for end-users, writing user guides, training guides, process and procedure handbooks (business and technical), and creating effective, accessible web pages. But I have also written informational leaflets, data sheets and case studies, reports, marketing copy, and general and technical newsletters and brochures for clients large and small.

In my spare time, I enjoy going out and taking photos (see more on my personal web site, https://lois.co.uk), and making pottery, not to mention reading and walking on the coast, which I assume everyone will do given the chance  🙂

Lois Wakeman, LRPS, BSc Hons

I am sometimes asked why anyone needs to use a technical author (TA), when most people can write English, and someone who develops a technical system or process (a programmer, financier, or engineer for instance) is bound to know it better than an outsider like me.

Making common sense of complex technical information

Well, the first answer I give is that a technical author is like a translator. He or she takes a body of technical information — whether on paper or in the subject matter expert’s (SME’s) head — and translates it into terms that are meaningful to the intended audience. For example, a functional specification is little help to the end user of a piece of software — the user does not generally care how or why it works, but just wants to know how best to use it to achieve a result. And different audiences may need a different slant on the same information — for example, in a medical system, clinical staff will have very different requirements from the technical support people.

Knowing what information is important for the reader

The second part of the answer is that being very close to a subject is not always the best position from which to describe it to others. If you know a lot about something, the tendency is to put it all in writing. A good technical author will be able to see what knowledge is essential to using a product successfully, and what is not. He or she will not be afraid to ask those stupid or embarrassing questions that would never occur to an expert. “Well, why does it work this way, and what happens if I do this instead?” “I don’t understand why I need to fill in these fields.” “The functional spec. isn’t the same as the real thing. Will you be changing one or the other?” The answers to these can add incalculable value to the content of a document, and sometimes to the usability of a product (see below).

Writing clearly, consistently and quickly

A third point that I am usually too tactful to mention is that not everyone is very good at writing information down anyway. Good technical writing is not just a matter of sticking to the rules of grammar and good usage. It is also about finding the right tone for an audience, making sure information is presented consistently in a logical order, is easy to find, and nicely presented. (All this without labouring for hours over each paragraph, of course.)

Testing usability – a free extra

As a bonus, a good author can also be a source of free usability testing for your product. Most of us will (if asked), point out any problems we notice in using or trying to describe the product.

How a document is written

Whatever information you want written professionally, the process for using a freelance technical author (TA) is much the same. The usual series of steps is listed below, but for a small job (a newsletter or a brochure for example), each one will be pretty informal. Note that getting the finished document requires input from the client well as the author!

1. Agreeing a proposal for the job, detailing how long it is likely to take, who is responsible for providing what, and a summary of the scope of the job. For complex jobs, a formal synopsis of the documentation will usually be produced.
2. Preliminary information-gathering by the author. Sources may include system/technical specifications, interviews with experts, and/or using a product to see what it does and how it works. Concurrently, a project plan and schedule will be worked out in consultation with the client.
3. Writing a first draft. The draft may contain questions or comments about alternative approaches for the reviewers.
4. Commenting on/reviewing the first draft. At this stage, the technical experts will usually be asked to correct any errors or confusion, and marketing experts will comment on the general approach.
5. Writing the second draft, incorporating comments and, if necessary, reconciling conflicting opinions.
6. Client review of the draft again. At this stage, comments should be relatively minor.
7. After incorporation of the final comments, preparation and approval, by the client, of the final draft.
8. For electronic documents, the final step is for the author to prepare the finished article (for example, a Word document, an Adobe Acrobat (PDF) file, or web pages. For paper documents, the author produces the necessary input, and may liaise with the printer to get the finished article.

Working with a remote contractor

I normally work mostly from my own office here in Devon, but with visits to client sites as necessary, for example to review comments and collect source material. Using the telephone, email and remote connections for the rest is usually an efficient way of running a documentation project.

If you are unused to working this way, you may be concerned that you do not control the job as closely as you are accustomed to. All I can say is that my clients are very satisfied with my work, and that, this way, you get 100% of what you pay for — I log all the time I spend on each job, and you are not charged for overheads like drinking coffee, checking email or non-work telephone calls. And since I work on my own, there is little opportunity for idle gossip around the water cooler!

The average production rate for an employed TA (insofar as such measurements mean anything) is about 10–12 A4 pages a week (not just drafting, but the whole process from initial information-gathering to finished draft), but I reckon on being able to do about 15 for most projects; more, if the work is straightforward.