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. |