The report as a document type
A technical report is a self-contained record of a piece of work: what question was asked, what was done, what was found, and what follows from it. Unlike an email or a set of notes, it is expected to stand on its own months later, for readers who were not present. Organisations, journals and universities often supply their own templates, and those take priority over anything general written here.
The sections below follow a widely used pattern. Names and order vary, but the underlying questions are the same.
How reviewers tend to read
Few people read a report in order. A typical reader looks at the title and abstract, scans the headings, jumps to the conclusions and key figures, and only then reads the method or results in detail if something needs checking. Some reviewers check the method first, because it tells them whether the results can be trusted.
This reading pattern is the main reason for the conventional structure. Each section has a predictable job, so that a reader can go straight to the part they need. Write each section so that it makes sense if read alone, and avoid making readers piece together a point from three places.
Title and abstract
The title should say what the work is about in specific terms. “Test of Bracket Fatigue Under Cyclic Load” tells the reader more than “Test Report”.
The abstract is a short summary, often a single paragraph, written last. It usually covers the purpose, the approach, the main results with key numbers, and the main conclusion or recommendation. It should be understandable without the rest of the report. Avoid putting references, undefined abbreviations or promises such as “results are discussed” in it; say what the results are.
Introduction
The introduction answers why the work was done. It gives enough background for the reader to follow, states the problem or question, and says what the report will and will not cover. A clear statement of scope matters here, because it sets expectations for how far the conclusions reach.
Keep the background proportionate. Readers of a report usually know the field; they need the context specific to this project, not a textbook summary.
Method
The method describes what you did in enough detail that a competent colleague could repeat it or judge whether it was suitable. Include the equipment or software used, the conditions and settings, how data was collected, and how it was processed. Where a recognised standard or procedure was followed, say which one and note any deviations from it.
Describe the method in the order things happened, and keep it separate from results. Mixing in findings here makes both sections harder to use. If something went wrong or was changed mid-way, record it, since reviewers value honesty about limits more than a tidy account that hides them. Good notes, such as those kept in technical notebooks, make this section much easier to write accurately.
Results
Results present what was observed, without interpretation. Use tables and figures for the main data, and use the text to point out what the reader should notice. Report the uncertainty or spread in your data where you have it, and give units throughout. The idea behind measurement uncertainty is worth understanding before you decide how many digits to quote.
Be selective. Put the data needed to support the conclusions in the body and move bulk data, raw tables and long derivations to an appendix. Do not leave unexplained figures for the reader to decode.
Discussion
The discussion is where you interpret the results. Explain what they mean, how they compare with expectations or earlier work, and what could explain surprises. Be open about limitations: small samples, assumptions, instrument limits, conditions that differ from real use. Distinguish clearly between what the data shows and what you think it suggests.
Some reports combine results and discussion, and short ones may do so sensibly. Longer ones usually benefit from keeping them apart.
Conclusions and recommendations
Conclusions should follow directly from the results and answer the question set out in the introduction. State them plainly, ideally as a short numbered list or a few brief paragraphs, and introduce no new data. If recommendations are requested, keep them separate from conclusions and make them specific: what should be done, by whom, and what remains uncertain.
Take care not to claim more than the work supports. A conclusion such as “the design met the requirement under the tested conditions” is more defensible than “the design is safe”. Where safety, regulation or quality are involved, rules vary by country and industry, so follow the standards that apply to you and rely on qualified professionals for sign-off.
References and appendices
List every source you drew on, using the citation style your organisation or publisher requires, and make sure each reference in the text appears in the list and vice versa. Appendices hold supporting material: raw data, calculations, drawings, code listings. Refer to each appendix from the body so it does not float unexplained.
Presentation details that reviewers notice
- Number sections, figures and tables consistently, and refer to them by number.
- Use the same terms and symbols throughout, and define abbreviations at first use.
- Include units on all quantities, and keep significant figures sensible.
- Keep a document history or revision number when the report may be updated.
- Proofread for numbers last, comparing text, tables and abstract against each other.
A short pre-submission check
Read the abstract, then the conclusions, and ask whether they agree. Then check that each conclusion can be traced to a result and each result to a method step. Ask someone unfamiliar with the work to read only the abstract and conclusions and tell you what they understood. If their summary differs from what you meant, revise those parts first; the rest of the document depends on them. For the broader principles of clarity that apply to every section, see the general guidance on technical writing, and for the formal specification-style documents that often precede a report, see technical specifications.