Technical Authorship

In its simplest form, technical authorship/technical writing is the use of words and pictures to provide easy-to-follow instructions in the form of technical manuals. We see our strengths as using our creative and technical skills to prepare documentation which communicates information in a clear and concise manner for its intended audience.

Why Use an Author?

A Technical Author is an expert in communicating information. You may have a large amount of information which may be highly complex, and you may need to communicate this to a wide range of people. A good technical author will be able to work out who needs to know what information; and devise the best method of giving them the information they need.

The choice of the correct writing style and documentation format is vital to the success of most technical manuals. We have enough experience to know what styles are most appropriate for different types of audience. We are happy to prepare work done using the principles of Plain English or Simplified English writing styles.

If you have a subject matter expert (such as a skilled R&D Engineer or a software developer), and ask them to produce the technical documentation, there is often a risk that they will assume too much knowledge or experience on the part of the user. Importantly too, they can often misunderstand the extent to which a user can think logically about the product and how it is intended to be used. They can also fall into the trap of thinking that technically-accurate writing is good enough to satisfy most users. If the person writing the documentation can not write in anything other than their own personal writing style, you may be creating some serious problems for the future. An experienced author will be able to place themselves "in the mind" of a novice end user, and write documentation which is appropriate for those users and their needs. This is especially true for documentation used by members of the public.

Technical authors are familiar with the concept of different writing styles; and most should be able to write in the style most suited to your users. For example, here at Red House, we are perfectly happy to write highly-technical documentation for API software developers; or to write easy-to-follow instructions for ordinary members of the public, or anything in between. The use of the correct writing style can have a positive effect on how the documentation will be used. It can prove to be highly beneficial in terms of recommending your products or your company.

What should go in the documentation?

Importantly, though, technical writing is far more than simply arranging the words on the page. As well as the ability to write in English to a high standard, a technical author must have the ability to assimilate new information quickly and decide how best to communicate that information. Authors also need to understand the technical background of the end users and their cultural heritage, as these can have a great impact on how those users make use of the product and its documentation. An experienced author should also be familiar with project management, version control and quality control procedures. For larger projects, it is increasingly the case that they will need to be familair with the concepts of content management systems and data re-use. Consequently, the final documentation is often the result of a fair degree of planning - best started at an early stage in the process. Knowing how to setup and structure projects and systems in mind can provide great benefits to improve the re-usability of knowledge, which can speed up the production of technical manuals later on.

In terms of developing documentation sets (such as user, installation and service manuals for the same product), a good author will also be ready to make a quick start on the documentation planning processes. In our experience, this planning phase covers some simple, but vitally important questions:

• Who am I writing for?
• What do they want to know?
• What is the best way to acquire this information?
• What is the likelihood that chunks of this information will need to be re-used elsewhere?

Asking these questions early on in the documentation cycle, helps the planning process for the documentation (as it then becomes much clearer what is actually needed), and it allows for deadlines and dependencies to be planned and met. Having advance notice of documentation requirements, helps bring the project in "on-time" and "on-budget" especially at the later stages of the project, when sourcing suppliers for printed materials.

In summary, engaging an author can prove highly beneficial, both for planning and in terms of education.  As experienced technical authors, we are happy to prepare a documentation plan in the early stages of the project; and then come back into the team later on when you are moving towards the final delivery deadline. Good planning can also help make project documentation work using "single-source" technologies - a very good way in which the production costs of documentation can be kept to a minimum.