Technical Communication By Mike Markel — A Field Guide

I ran into this book back when I was writing API docs for a medical device company. The kind of place where a single ambiguous sentence in a procedure manual could get you cited by the FDA. Most of us learn the hard way that technical communication isn't just about being clear — it's about being *defensible*. Clear enough that a regulator can read it and not file a 401(k). The textbook covers a lot of ground: document design, visual communication, proposals, reports, digital media, ethics. It's the kind of thing they assign in junior-level engineering or pre-med programs. I've since used it as a reference more than a cover-to-cover read, mainly for its sections on usability testing and audience analysis.

How Technical Communication By Mike Markel Actually Works in Practice

The framework is built around the concept of *rhetorical situation* — who's reading, what do they need, what's at stake if they get it wrong. It sounds abstract until you're writing a warning label for a defibrillator and someone argues the word "shock" is ambiguous. The book teaches you to do what we call a *task analysis* before you write a single sentence. Break down every step the user will take. Map it against what they already know. Then write for the gap between those two things. This is the part most people skip because it takes time. In my experience, a 20-minute task analysis saves three hours of revision later. I had a situation where a client wanted a quick-style installation guide for a piece of lab equipment. Standard one-page PDF. I did the task analysis and discovered the device had three distinct configuration paths depending on whether the user was calibrating for pH or conductivity or turbidity. The original brief didn't mention this at all. I split it into three separate quick-reference cards instead of one confused monolith. The client was initially annoyed at the extra work. Then their support tickets dropped by 60 percent the next month.

Key Sections and What They're Actually Good For

The *proposal and report writing* chapters are solid for anyone who needs to write internal documents — scope statements, progress reports, after-action reviews. The structure isn't groundbreaking, but it's consistent and repeatable, which matters when you're turning these out weekly. The *visual communication* section gets some criticism for being textbook-dry, but it covers things most people overlook: color contrast ratios for accessibility, table design that doesn't break when printed, the difference between a diagram and a chart. I've seen engineers spend 45 minutes arguing with a vendor about figure resolution because they never learned what 300 dpi actually means for a printed manual. The book explains it. You just have to read the right chapter. The *digital and multimedia* chapters are the weakest. They were written before AI-generated content and LLM-assisted drafting became standard practice. The advice is still structurally sound — write for scanability, use headings consistently, test on real devices — but some of the tool recommendations are dated.

Common Mistakes People Make With This Material

The biggest one I see is treating the book as a style guide when it's really a *process* guide. You don't memorize the templates. You learn the workflow: analyze audience, define purpose, research, draft, test, revise. The templates are scaffolding. Remove them once the structure is internalized. Another mistake is skipping the ethics chapters. People think ethics means "don't plagiarize." It also means "don't downplay failure modes" and "don't write instructions that assume competence the user doesn't have." I worked on a project once where the safety warnings were technically accurate but written in a way that made them look like boilerplate. Users ignored them completely. We rewrote them using plain language and placed them inline with the relevant procedure steps. Compliance went up. Not because the rules changed, but because the communication did.

What Technical Communication By Mike Markel Doesn't Cover Well

It doesn't address AI-assisted writing workflows, which is a real gap now. It doesn't cover localization at depth — how to write for translation, not just English speakers. And it barely touches on iterative design processes like agile documentation, where the document evolves alongside the product rather than being produced as a final artifact. If you're working in a modern tech environment, pair this with something like *The Elements of Style* for prose mechanics and a quick reference on WCAG 2.2 guidelines for accessibility. The combination covers more than any single textbook.

When to Use It and When to Move On

Use this if you're writing procedural documents, user manuals, or internal reports and you want a structured approach that won't fall apart under scrutiny. It's especially useful if you're in a regulated industry where documentation is auditable. Move on to something more specialized if you're writing code documentation, API references, or developer-facing content. This book is aimed at general technical communicators, not software engineers. The audience analysis framework transfers, but the examples and exercises won't match your actual work. I keep a copy on my desk. Not because I refer to it daily, but because when I'm stuck on a structural problem — how to organize a complex procedure, when to use a table versus a list, how to balance completeness against usability — it has a section on exactly that. It's not inspiring. It's reliable. In this field, reliability beats inspiration every time.