Translating Technical Findings Into Plain Language
Customer/User Communication for Support
Chapter 2 · Translating Technical Findings Into Plain Language
Chapter 1 established the core claim: being right and being understood are different achievements. This chapter delivers the first concrete skill for closing that gap — turning a technical finding into plain language without losing what made it accurate in the first place.
Jargon Isn't a Problem of Intelligence
Jargon fails a listener not because the underlying concept is too hard for them, but because it's unfamiliar vocabulary standing in for something they could understand perfectly well if explained in terms they already have. The problem is a vocabulary mismatch, not a comprehension ceiling.
Translate, Don't Dumb Down
This is the crucial distinction. Dumbing down removes real information or accuracy to make something feel simpler — and often ends up less accurate, or even patronizing. Translating keeps exactly the same information, re-expressed using concepts and words the listener already has. Chapter 1's own central claim demands translation specifically, since dumbing down often sacrifices the very accuracy that made the original explanation correct.
Techniques for Translating Well
- Analogy to something familiar — a comparison to something the listener already understands, used carefully, since a bad analogy misleads just as effectively as jargon confuses
- Effect before mechanism — lead with what the user actually experienced or will experience, before (or instead of) how it technically works internally
- Define a necessary term inline — the first time an unavoidable technical term is used, define it briefly rather than either avoiding it entirely or assuming it's already known
- Cut unnecessary technical detail — not every accurate detail is a necessary one; `docs1`'s own "cut what a reader doesn't need" reasoning applies here just as directly to a conversation as it does to a runbook
Necessary vs. Unnecessary Detail
Accuracy doesn't require including every true fact — it requires that everything included is true, and that nothing misleading is omitted. Deciding which true details a listener actually needs is itself a real skill, not a compromise of accuracy.
Worked Example: A Genuine Translation
| Version | |
|---|---|
| Jargon | "The API's connection pool was exhausted due to a slow query holding a lock." |
| Plain language | "The system got overloaded because one part was taking too long to finish, which backed everything else up behind it — we've fixed the slow part." |
Every fact in the plain-language version is true. Nothing misleading was introduced, and nothing essential to what the user actually needs to know was cut — this is translation, not simplification that sacrifices truth.
Hands-On Exercises
Explain the specific difference between "translating" and "dumbing down," and why dumbing down is described as a risk to the accuracy Chapter 1's own central claim requires preserving.
📄 View solutionUsing the worked example, explain why the plain-language version counts as an accurate translation of the jargon version, rather than a simplification that lost information.
📄 View solutionExplain why a bad analogy is described as actively harmful rather than merely unhelpful, and how the chapter's own test for an analogy is meant to catch this before it's used.
📄 View solutionChapter 2 Quick Reference
- Jargon is a vocabulary mismatch, not a comprehension ceiling
- Translate, don't dumb down: re-express the same information, don't remove accuracy to feel simpler
- Use analogy carefully, lead with effect before mechanism, define necessary terms inline, cut unnecessary detail
- Accuracy requires that included facts are true and nothing misleading is omitted — not that every true fact is included
- A bad analogy is worse than no analogy — test it by thinking it through one step further before using it
- Next: Chapter 3, setting expectations before you start