Technical writing

Engineers write far more than most students expect: surveys of practising engineers regularly find them spending a large share of the working week on reports, memos, emails, specifications and proposals. An excellent design that is badly explained may never be approved, funded or built correctly. A clear report, on the other hand, gets decisions made quickly and protects everyone if questions are asked later.

Technical writing is not literary writing. Its goal is not to impress but to transfer information accurately with the least effort for the reader. This chapter covers how to plan for your reader, structure the common document types, write plain and precise sentences, present numbers, units, figures and tables correctly, cite sources, and revise. We finish the entrance project by writing its recommendation.

Start with the reader

Before writing anything, answer three questions.

• Who will read it? The community centre board, a city plans examiner and a contractor all need different things from the same project.
• What do they need to do after reading? Approve, decide, build, check, file?
• How will they read it? Most busy readers skim: they read the title, the first paragraph, the headings and the figures, and dive into detail only where they must.

Write for the least specialist reader who must act on the document, and put detail where specialists can find it (appendices, attached calculations). A board member does not need the drainage calculation, but the plans examiner does.

Put the answer first

Academic writing often builds to a conclusion: background, method, results, and finally the answer. Professional readers want the reverse. Lead with the conclusion or request, then give the support. The military calls this BLUF, "bottom line up front", and it works everywhere.

Common document types

• Email: one topic per message, request or answer in the first two lines, short paragraphs. Assume it may be forwarded to anyone.
• Memo: a short internal document (one to three pages) with To, From, Date and Subject lines, used for progress updates, decisions and short technical findings.
• Design report: the full record of a design: the problem, requirements, concepts considered, the recommended design, its analysis and verification, cost and schedule. It is often the document that is sealed and kept for decades.
• Proposal: a persuasive document asking for approval or money to do work, setting out what will be done, how, by whom, when and for how much.
• Lab or test report: what was tested, how, what was measured, and what it means, with enough detail for someone else to repeat the test.
• Specification: the contractual statement of what must be supplied and to what standard. Its language is deliberately precise ("shall"), as in Lesson 2.

Structure of a design report

A design report usually follows this order, with the front matter written last:

The executive summary is the most important page you will write. It must stand alone, because many decision-makers will read nothing else. In half a page to a page, it states the problem, the recommendation, the key reasons, the cost and schedule, and any decision or action needed. It contains no new information that is not in the report, and no references to figures the reader cannot see.

Write plainly and precisely

Plain language is not dumbing down. It is respect for the reader's time. A few habits make most of the difference.

• Prefer short sentences. Aim for an average of 15 to 20 words, with variety. One idea per sentence.
• Use concrete words. "The beam is overstressed by 15%" beats "There may be some concerns regarding the adequacy of the beam."
• Cut empty phrases: "in order to" (to), "due to the fact that" (because), "at this point in time" (now), "it should be noted that" (delete).
• Use the active voice when the actor matters: "The contractor shall remove the old steps" makes responsibility clear; "The old steps shall be removed" does not say by whom. The passive is fine when the actor is unknown or irrelevant, as in describing a test method.
• Turn hidden verbs back into verbs: "make a decision" (decide), "carry out an analysis of" (analyse).
• Define abbreviations on first use, and use each term consistently. If you call it the "walkway" in section 2, do not call it the "path" in section 5; the reader may think it is something else.

Measuring readability

Readability formulas estimate how hard text is to read from sentence and word length. The Flesch Reading Ease score is one of the oldest:

Higher is easier: 60 to 70 is plain English, below 30 is very difficult. Technical text scores lower because technical words are long, and that is acceptable. But a low score is a prompt to look for long sentences and needlessly long words.

Numbers and units

In engineering documents, numbers are the content. Small formatting errors make readers doubt the larger ones. Follow the SI conventions:

• Leave a space between a number and its unit symbol: 25 mm, 4.5 kN, 20 °C. (The percent sign is often closed up in North American usage: 15%.)
• Unit symbols are case-sensitive and never pluralized or followed by a period: kg not Kg or kgs; kN not KN; m not M (which is the prefix mega); s not sec.
• Use a space, not a comma, to group digits in long numbers in technical work: 12 500 N. In Canada the comma is the decimal marker in French, so commas in numbers can be misread.
• Do not mix symbols and words: "kilonewtons per metre" or "kN/m", not "kN per metre".
• Put a zero before a decimal point: 0.73 L/s, not .73 L/s.
• Write dates unambiguously. 03/04/2026 means March 4 in some places and April 3 in others. Use 2026-04-03 (ISO 8601) or write the month as a word.

Significant figures and precision

Report results to a precision that reflects the inputs. If the rainfall intensity is known to two or three significant figures, a calculated flow of 0.7333 L/s implies a precision that does not exist; report 0.73 L/s. Excess digits are not more accurate; they are less honest. Carry extra digits through calculations and round only the final reported result, as in ENGG-130.

Figures and tables

A good figure can replace a page of text, and a bad one can mislead. Every figure and table should:

• Be numbered and have a caption that says what it shows, and ideally what the reader should notice ("Figure 3. Weighted score against cost weight; the walkway leads only below 0.39.").
• Be referred to in the text before it appears ("as Figure 3 shows…"). Never include a figure the text does not discuss.
• Have labelled axes with units, readable fonts, and a legend only when needed (direct labels are usually clearer).
• Avoid decoration: no 3D bars, shadows, or colour that carries no meaning. Do not rely on colour alone, since some readers have colour vision deficiency and many documents are printed in greyscale.

Use a table when readers need exact values; use a graph when they need to see a trend or comparison. In the common IEEE style, table captions go above the table and figure captions below the figure.

Watch for truncated axes in particular. A bar chart whose axis starts at 6.0 instead of 0 makes a 6.95 bar look several times taller than a 6.75 bar. For bar charts, start the axis at zero; for line graphs of a trend, a non-zero axis can be fine if it is clearly marked.

Citing sources

Every fact, figure, method or code requirement you did not create yourself needs a citation. Citations let readers check your work, give credit, and show that your design rests on authoritative sources. Engineering commonly uses IEEE style: numbered references in square brackets in the order they are first cited, with a numbered list at the end.

Using someone else's words, figures or ideas without citation is plagiarism, at university and at work. In professional practice it can also be a breach of the code of ethics and of copyright. The same applies to text produced with AI writing tools: you are responsible for every statement in a document with your name (or seal) on it, so check facts, numbers and citations yourself, and follow your school's or employer's policy on their use.

Revising

Nobody writes a clear document in one pass. Separate drafting from editing, and edit in layers, from big to small:

• Structure: is the answer first? Does each section do one job? Would a skimmer get the point from the headings and first sentences?
• Content: is every claim supported? Are numbers consistent between the summary, text, tables and appendices? (Inconsistent numbers are the most common error in student and professional reports alike.)
• Sentences: cut, simplify, activate.
• Details: units, figure numbers, references, spelling, page numbers.

Leave time between drafting and editing, read the document aloud to catch awkward sentences, and ask a colleague to read it as the intended reader would. In engineering firms, reports are checked by a second engineer before they are issued, for the same reason calculations are.