Technical writing Study Guide

📖 Core Concepts Technical Writing – Communicates complex scientific/industrial info to varied audiences (customers, engineers, assembly workers, etc.) using clear text and visuals. Plain Language – Simple words, short sentences, no personal pronouns or obscure acronyms; ensures every reader understands factual content. Visual Communication – Diagrams, illustrations, CAD‑exploded views paired with text to clarify difficult concepts. Procedural Writing – Step‑by‑step, numbered instructions written in third‑person active voice for both experts and laypeople. Scientific/White‑Paper Writing – Persuasive documents that use industry terminology, data, and a bias toward the author’s conclusions; targets knowledgeable readers. Standardized Styles – DITA, Markdown, AP Stylebook, Chicago Manual, etc., enforce uniform formatting, grammar, and tone across all documents. Roles – Technical Writer: style, formatting, clarity; Subject‑Matter Expert (SME): technical accuracy. Collaboration – Writers translate engineers’ input; engineers rarely draft documentation themselves. 📌 Must Remember Plain language = simple terms + short sentences + no personal pronouns. Procedural docs must use third‑person, active voice and a formal tone. Uniform documentation = consistent format + grammar + style → no reader confusion. Major document types: API docs, Assembly Instructions, SOPs, User Manuals, Installation Manuals, Specification Sheets, White Papers, Case Studies. Core tools: Wiki/Confluence, CMS/CCMS (store, version‑control, publish in XML/HTML). 🔄 Key Processes Gather Requirements – Meet with SMEs, collect data, define audience and scope. Plan Structure – Choose document type (procedure, API, SOP) and select a standardized format (DITA, Markdown). Draft Content – Write in plain language, third‑person active voice; number each procedural step. Create Visuals – Produce diagrams, CAD explosion views, screenshots; embed alongside relevant text. Review Cycle – SME verifies technical accuracy; writer checks style, grammar, and uniformity. Publish – Upload to CMS/CCMS or wiki; ensure searchable metadata and version control. 🔍 Key Comparisons Procedural Writing vs. Scientific Writing Procedural: numbered steps, active voice, audience may be layperson. Scientific: argumentative, data‑heavy, industry‑specific jargon, persuasive bias. API Documentation vs. User Manual API: developer‑focused, includes function signatures, request/response examples, often auto‑generated. User Manual: end‑user focused, explains how to operate hardware/software, includes safety warnings. CMS vs. Wiki CMS/CCMS: robust versioning, component reuse, supports XML/HTML publishing. Wiki: lightweight collaboration, easy editing, less formal control over structure. ⚠️ Common Misunderstandings “Technical = jargon‑heavy.” – Effective tech writing avoids unnecessary jargon; use it only when the audience expects it. “Active voice is optional.” – In procedural docs, active voice is required for clarity and safety. “Writers can write without SMEs.” – Writers rely on SMEs for technical correctness; skipping this step leads to errors. 🧠 Mental Models / Intuition “Audience‑First Lens” – Imagine the reader’s knowledge level; if a sentence feels “too smart,” simplify it. “Step = Action + Result” – Each procedural step should state what to do and what the expected outcome looks like. “Visual‑Text Pairing” – Pair every complex concept with a simple diagram; the diagram answers the “how?” while text answers the “why?”. 🚩 Exceptions & Edge Cases Regulatory Documents (e.g., construction specifications) require formal sign‑off and may retain legal terminology. API Docs for Public SDKs often need code samples in multiple languages; plain language still applies but technical syntax is unavoidable. White Papers may intentionally include persuasive bias; still must cite data accurately. 📍 When to Use Which Need step‑by‑step guidance? → Write a Procedural SOP / User Manual. Describing functions for developers? → Create API Documentation (auto‑generated markdown). Selling a high‑tech product to experts? → Draft a White Paper with data and industry terminology. Providing quick troubleshooting? → Publish a Knowledge‑base article in a CMS/CCMS. Documenting construction standards? → Use a Specification Sheet with signed approvals. 👀 Patterns to Recognize Numbered Lists → Indicates procedural content. “Figure X shows…” → Visual aid supporting a complex description. “The purpose of this document is…” → Scope statement, typical of formal specs or SOPs. “Version x.y” → Indicates living documents (API docs, CMS‑managed articles). 🗂️ Exam Traps Choosing “personal pronoun” as acceptable – Plain language prohibits “you,” “we,” etc. Assuming all technical docs are written in passive voice – Procedural docs must be active. Mixing document types – Selecting “User Manual” for a developer‑focused API question will be wrong. Over‑relying on jargon – If the audience includes laypersons, heavy terminology is a distractor. Forgetting visual aid requirement – Questions that omit diagrams for complex processes often signal an incomplete answer.