Technical writing, engineering specifications, reports, presentations, and documentation standards for engineering practice. Covers document types (requirements documents, test reports, design rationale, operations manuals), writing style, data visualization, engineering drawing standards, and oral presentation techniques. Use when writing engineering documents, presenting technical results, creating specifications, or learning documentation best practices.
Engineering that cannot be communicated is engineering that does not exist. The finest analysis is useless if the reader cannot follow it. The most thorough test is wasted if the report does not document what was tested, how, and what was found. Technical communication is not a soft skill appended to engineering -- it is a core engineering competency. This skill covers the full range of engineering communication: written documents, visual presentations, engineering drawings, and oral delivery.
Agent affinity: polya-e (pedagogical communication, scaffolded explanation), johnson-k (technical precision, NASA documentation standards)
Concept IDs: engr-design-communication, engr-testing-methodology, engr-data-from-experiments, engr-codes-of-ethics
Engineering writing serves one purpose: to transfer technical information from the writer's mind to the reader's mind with minimum distortion. Every sentence should advance this transfer. Sentences that do not transfer information are noise.
Bad: "It is important to note that the utilization of advanced computational methodologies was employed in the determination of stress distribution."
Good: "We computed stress distribution using finite element analysis."
The good version says the same thing in half the words with double the clarity.
Engineering writing is precise. Numbers have units. Claims have evidence. Conclusions follow from data.
Imprecise: "The beam was strong enough."
Precise: "The beam sustained a 50 kN point load at midspan with 12 mm deflection, within the L/360 serviceability limit of 14 mm."
Engineering documents follow predictable structures because readers need to find information quickly. An engineer reviewing a test report at 2 AM during an integration crisis does not want a narrative -- they want the result in a predictable location.
The same technical result is communicated differently to different audiences:
| Audience | What they need | How to write |
|---|---|---|
| Fellow engineers | Full technical detail, assumptions, limitations | Formal, precise, equations and data tables |
| Management | Summary, implications, decisions needed | Executive summary, key findings, recommendations |
| Regulators | Compliance evidence, traceability | Structured by regulation section, explicit requirement mapping |
| Public | What it means for them, safety implications | Plain language, analogies, no jargon |
Purpose: Define what the system must do.
Structure:
Style rule: Each requirement is a single sentence. "The system shall..." format. One requirement per numbered item. No compound requirements ("shall do A and B" -- split into two requirements).
Purpose: Document what was tested, how, and what was found.
Structure:
Style rule: The reader should be able to reproduce the test from the report alone. If they cannot, the report is incomplete.
Purpose: Explain why this design was chosen.
Structure:
Why it matters: Design rationale documents prevent future engineers from re-fighting settled decisions. When someone asks "why did we choose a cable-stayed bridge instead of an arch?" five years later, the design rationale document provides the answer.
Purpose: How to use, maintain, troubleshoot, and repair the system.
Structure:
Style rule: Written for the operator, not the designer. Use the operator's vocabulary. Include illustrations. Never assume the reader has engineering background.
Engineering drawings are the legal definition of a part or assembly. They must conform to standards (ASME Y14.5 in the US, ISO 128 internationally).
Key elements:
The drawing rule: A competent machinist with only the drawing (no verbal explanation) should be able to produce a conforming part. If they cannot, the drawing is incomplete.
| Use a table when | Use a figure when |
|---|---|
| Exact values matter | Trends and patterns matter |
| Few data points | Many data points |
| Comparison across categories | Relationships between variables |
| Reference lookup | Spatial or temporal relationships |
Edward Tufte's guidelines for data visualization:
| Section | Time allocation | Content |
|---|---|---|
| Introduction | 10% | Problem, scope, why it matters |
| Body | 75% | Approach, results, analysis |
| Conclusion | 10% | Key findings, recommendations, next steps |
| Q&A | 5%+ | Prepared for likely questions |
NASA documentation standards (NPR 7120.5, NPR 7123.1) provide a reference framework for technical communication in complex systems:
These standards enforce structure, peer review, and traceability -- the same principles that apply to all engineering communication, formalized for the highest-stakes environment.