Technical Writing Genres

Listed below are some of the more common genres one might expect to encounter in the technical writing profession. Many of the sources listed in the Supplemental Bibliography contain samples of these deliverables. In addition, further information and samples can be found in Professional Writing Online and on the Web.

It is important to bear in mind that a technical writing course (or any composition course, for that matter) should not be genre-based. For example, a memo is not written in isolation--it exists in a context and has a purpose within that context. Therefore, it is best to think of a technical writing course as project-based. Genres are selected because they fill the particular needs of a project.

Memorandum
In technical writing, memos are typically used to introduce projects, update your client/audience on a project's progress and to provide assessment information at the conclusion of a project.

A memo usually passes between people who have already established contact and are getting further business done on a project. A memo is part of an ongoing conversation between colleagues, whether the colleagues are within the same company or working together on a joint project involving several companies. In technical environments, memos are often sent so that they can be added to the project file, creating a paper trail that may be useful later if a history of the process is needed for legal or management purposes. (Writing for the Technical Professions, Woolever 144)


White Paper
A white paper is similar to a traditional research paper. The main difference lies in its form. Information is presented in sections rather than in a straight essay form. You might find the topical headings a "freeing" substitute for transition sentences/paragraphs. The writing style is more "chunked" than expressive. In addition, use of bullets, numbers, charts, and tables are common.

A white paper is an article that states an organization's position or philosophy about a social, political, or other subject, or a not-too-detailed technical explanation of an architecture, framework, or product technology. Typically, a white paper explains the results, conclusions, or construction resulting from some organized committee or research collaboration or design and development effort. A white paper is a 10-20 page piece whose production values fall between a manual and a brochure...The white paper is a versatile vehicle. It can address

any subject that can be covered in 30-60 minutes of reading time. (A good white paper begins with a summary or introduction that helps managers decide whether to read the rest of the paper or pass it to a colleague or subordinate.) (http://www.topoz.net/wpdef.html 1)


Informal Usability Report
The informal usability report takes the form of a memo. Like many technical writing documents, it is sectionalized. Typical sections are an Overview (contains statement of problem, proposed task, and any necessary background information), Recommendations, Methods/Approach, Findings/Results, and Appendices. In testing the usability of a product or documentation, one might also be called upon to write and administer questionnaires, surveys, or other testing tools.

Companies routinely measure the usability of their products--including the documentation that accompanies the product (warnings, explanations, instructions for assembling or operating and so on). To keep their customers-- and to avoid lawsuits--companies go to great lengths to identify flaws or to anticipate all the ways a product might fail or be misused. The purpose of usability testing is to keep what works in a product or a document and to fix what doesn't. (Technical Communication, 8th ed., Lannon 36)

Documentation
To put it in simple terms, documentation equals instructions. Most likely, we encounter some sort of documentation everyday. Computer manuals, Help windows, and quick reference guides are common examples of documentation. It is of utmost importance that documentation be usable.

"For a document to achieve its objectives- to be usable- users must be able to do at least three things (Coe, Human Factors 193; Spencer 74):
- easily locate the information they need,
-understand the information immediately, and
-use the information successfully.
To measure usability in a set of instructions, for instance, we ask this question: How effectively do these instructions enable all users to carry out the task safely, efficiently, and accurately?" (Technical Communication, 8th ed., Lannon 36)