
There is a fear that sits behind almost every technical communication project, usually unspoken, sometimes said out loud in the first meeting.
If we simplify this, we’ll get it wrong. The engineers will wince. The analysts will notice. We’ll look like we don’t understand our own work.
It is a legitimate fear, because bad simplification does exactly that. But it rests on a false choice, the idea that communication runs on a single dial with “accurate but impenetrable” at one end and “clear but wrong” at the other. It doesn’t. Dumbing down and clarity are not points on the same scale. They are different operations entirely.
Dumbing down removes substance. Clarity removes obstacles.
Dumbing down takes a true, precise statement and replaces it with a vaguer, rounder one. It swaps mechanism for mood. It deletes the numbers because numbers are hard, and the caveats because caveats are boring, until what remains is technically related to the truth but no longer carries it. Experts wince at dumbed-down work because something real has been lost.
Clarity does the opposite. It keeps the substance and strips away everything standing between the substance and the reader. The jargon that carries no meaning outside the building. The sentence built for a peer reviewer rather than a person. The assumption that the audience already knows why any of this matters. Nothing true is removed. What is removed is friction.
The test is simple, and we apply it constantly. Show the clear version to the expert who knows the subject best. If they wince, something was lost and the work is not done. If they say “yes, that’s exactly it, I wish I could explain it like that,” you have found the band. It is narrow, and it is the entire job.
What the work actually looks like.
Finding that band is not a writing trick. It is a sequence, and it starts with understanding the subject properly ourselves. You cannot simplify what you have not genuinely understood, which is why the first phase of our projects looks less like an agency and more like an interrogation. What does this process actually do? Why this design and not the obvious alternative? What would a sceptic push on?
Then comes the hard part: deciding what the audience needs, rather than everything the subject contains. A ten-minute animation of a facility does not show every valve. It shows the fifteen things that make the engineering make sense, in the order that builds understanding, and it earns the audience’s confidence that the detail exists underneath. Precision about what to include is where most technical communication fails. Not because the detail was wrong, but because all of it arrived at once.
And the numbers stay. This matters. Clear work does not delete quantities, it gives them footing. “Enough gas to supply a small country for a decade” is not less accurate than the raw figure. It is the raw figure, made weighable by a human mind. An analogy chosen precisely is an act of accuracy, not a retreat from it.
The narrow band is worth the effort.
Work that lands in that band does two jobs at once. The non-expert finally gets it: the regulator’s advisor, the local councillor, the generalist investor, the new starter. And the expert still recognises their work in it, which means they will stand behind it, present it, and defend it.
Miss on either side and the work fails differently. Too technical, and it only speaks to people who already understood. Too soft, and the people whose respect you need disown it, quietly or otherwise.
Making a complex thing genuinely clear is more work than leaving it complicated. It takes subject-matter understanding, editorial nerve and a willingness to keep asking the expert “have we lost anything?” until the answer is no. That work is the job. It is also, not coincidentally, the work most worth paying for, because the alternative is communication that either nobody understands or nobody trusts.
Common questions.
How do you simplify technical content without making it inaccurate?
+
Won’t our technical audience be put off by simplified communication?
+
How much detail should technical communication include?
+
Are analogies risky in technical communication?
+
Who should sign off clear versions of technical content?
+
Tell us the subject. We’ll find the band.
Start a conversation.