How to Write a Technical Manual

Write down who will use the manual and what they must be able to do with it. A manual for a crew performing daily checks is a different document from one for a depot technician rebuilding an assembly. Then list the tasks: each inspection, removal, installation, adjustment, test, and repair the reader will perform. That task list is your table of contents in embryo, and gaps in it become gaps in the manual.

Sit with the product and someone who maintains it. Watch the task being done and note the tools, the hazards, and the points where the engineer's drawing and the real work disagree.

Before drafting, find out what the manual must conform to. In defense and aviation the contract or regulation names it: see which MIL-STD governs a manual and which writing standards apply to which layer. For machinery and products sold in the EU, the choice is often between ISO 20607 and IEC/IEEE 82079-1. Settling this first matters because the standard decides the structure, the safety-message conventions, and the delivery format, and all three are expensive to change later.

Group the tasks into the chapters or work packages the standard expects, and decide which documents make up the set: operation, maintenance, parts, and any wiring or structural volumes. Plan the set before you write page one, because cross-references between volumes are far easier to build than to retrofit. Our overview of technical manual families shows how the sets are usually divided.

Each procedure covers one task. State what must be in place first (tools, parts, consumables, access, conditions), then give numbered steps, one action per step, in the order the work is done. Use the imperative, name the part as the drawing and the parts list name it, and give every value its unit. End with the check that tells the reader the task is complete.

Where the contract asks for a controlled language, apply it from the first draft; see writing to ASD-STE100 in practice. Retrofitting it onto approved text is harder than starting with it.

Put every warning, caution, and note before the step it concerns, never after. Use the signal words and formats your governing standard defines, and do not invent your own. Our guide to warnings, cautions, and notes covers the severity levels and where each kind of message goes.

Show what the words cannot: location, orientation, sequence, and exploded views. Each figure should serve a step and carry callouts the text uses. Decide early on the file format, because it affects accessibility, scaling, and reuse; see vector or raster and, for defense drawings, the ASME Y14 drawing standards.

Review checks the draft against its sources: technical accuracy, style, and conformance to the standard. Validation checks it against the product: someone performs each procedure exactly as written, on the equipment or an approved representation of it, and every discrepancy is recorded and resolved. Do not treat the second as a repeat of the first. A step can read perfectly and still fail on the bench.

Government programs formalize this; see TM validation and verification and the common causes of rejected manuals.

A manual is never finished. Product changes, service findings, and errata all need a path back into it. Assign a revision identifier, record what changed and why, and tie each issue to the configurations it covers. For aviation specifics see revision control for aviation manuals. If many manuals share content, a structured approach avoids updating the same step in ten places; see single-source publishing.