How to Write a Technical Report

A technical report is read by people with very different levels of expertise, often skipping to different sections.

Technical reports document work done — an experiment, a design, an investigation, a system build — in enough detail that a competent reader could evaluate or repeat it. They are read non-linearly by an audience with mixed expertise, which is why the structure is more rigid than in most academic writing.

Write for several readers at once

A single report may be read by a supervisor checking the method, a manager who reads only the summary, and an engineer who will build on the work. These readers need different things, and the conventional structure exists to serve them simultaneously.

Practically, that means the summary must stand alone, the body must be complete, and the appendices must hold detail that would obstruct the argument if included inline.

Follow the expected structure

Conventions vary by discipline and institution, but the core sequence is stable.

• Title page and abstract — what was done and what was found.
• Introduction — the problem, the objectives, the scope.
• Background or theory — only what the reader needs.
• Method — what was done, in reproducible detail.
• Results — what was observed, without interpretation.
• Discussion — what it means, and its limitations.
• Conclusions and recommendations — what follows.
• References and appendices.

Make the method reproducible

The test is whether a competent reader could repeat the work and expect the same result. That means equipment with specifications, software with versions, parameters with values, and procedures in enough sequence to be followed.

Where you deviated from a standard procedure, say so and why. Undocumented deviation is the most common reason results cannot be reproduced.

Report results without interpreting them

Keeping results and discussion separate lets a reader accept your data while disputing your reading of it, which is exactly what technical scrutiny requires. Results state values, trends and observations; discussion supplies causes, comparisons and implications.

Report uncertainty alongside values wherever your discipline expects it, and be consistent about significant figures across comparable measurements.

Present data in the right form

Tables suit precise values and many variables; graphs suit trends, relationships and comparisons. Do not present the same data as both. Every table and figure needs a number, a caption that stands alone, units, and a reference in the text explaining what it shows.

Check that figures remain interpretable in greyscale, since technical reports are frequently printed without colour.

Handle calculations transparently

Show the governing equation, define every symbol, state the values used, and give the result with units. A worked example in the body with the full set in an appendix is usually the right balance — a reader needs to see that the method is sound without wading through every iteration.

Where software performed the calculation, name it and state the settings that affect the result.

Use appendices deliberately

Appendices hold material a reader may want and does not need: raw data, full derivations, code listings, datasheets, calibration certificates. Everything there should be referenced from the body, and nothing essential to following the argument should live there.

Keep the language precise and plain

Technical writing values unambiguity above elegance. Prefer the specific term to the general one, define acronyms on first use, and avoid words that carry imprecise magnitude — “significant”, “large”, “rapid” — where a number is available.

Passive voice remains conventional in method sections in many disciplines, though several now prefer active. Check your department’s guidance and apply it consistently rather than switching.

State limitations and recommendations separately

Limitations describe what the work cannot establish; recommendations state what should happen next. Merging them produces vague statements that neither bound the findings nor propose action. Recommendations should be specific enough to be acted on, with an indication of priority where there are several.

Manage version control and collaboration

Technical reports are frequently written by several people and revised repeatedly. Agree early where the document lives, how versions are named, and who has final editorial authority. Emailed attachments with names like “report_final_v3_JS” are how sections get lost and superseded figures reappear in submissions.

Where a report includes code or data, keep those under the same version discipline as the document, and record which version produced which figure.

Check the report against its brief

Before submitting, reread the original specification alongside the finished report and confirm that every requirement is addressed and every stated deliverable is present. Technical briefs frequently contain explicit requirements — a particular analysis, a specified format, a required appendix — and omitting one is the most avoidable way to lose marks on otherwise competent work.

Write the summary for someone who reads nothing else

Technical reports are frequently circulated to people who read only the abstract or executive summary and act on it. That section must therefore contain the outcome, not a description of the investigation. State what was done, what was found, and what follows, in a form that survives being read alone.

Proofread the numbers separately

Reading for prose and reading for figures are different tasks, and doing them together catches neither reliably. Make a dedicated pass checking that every number in the text matches its table, that units are consistent, that significant figures do not vary between comparable values, and that every figure and table referenced actually exists. Numerical inconsistency undermines a technical report faster than any writing weakness.