After a review of some documents last week, a subject-matter expert told me essentially that one of the first principles of technical writing is to assume that the reader knows nothing about the subject matter.
I saw a couple of things wrong with this, and so I would revise the SME’s statement to make two corresponding and related basic principles of technical writing:
- Know your audience.
- Never assume anything, whether it’s about your audience or the subject you’re writing about.
Read on for some discussion:
Know Your Audience
This is a basic principle of any type of writing, but how often do you find yourself thinking of your audience as you’re writing or editing? I probably don’t do it as much as I should. At times I just write about subjects rather than writing for or to someone specific. Even if we do think of the audience, we can’t produce content with them in mind if they’re a faceless, nameless group of people. Even personas don’t help if they’re not based on facts.
Regarding the SME’s ideas, I’ll grant that if the audience indeed knows nothing—and we know for a fact they know nothing—then we would write to that level. We often do have to write for those who have no idea how to accomplish something. But the danger of that is the possibility that we think of that audience so much that we forget to do any research and find out when it doesn’t apply.
Never Assume Anything
On a related point, it’s not safe to assume that the audience’s level of prior knowledge (or anything else) about them. This is the problem that an interaction designer I knew had with personas; he said they’re too often based on assumptions and generalizations rather than research. He believed they’re used as a substitute for real audience analysis.
It’s easy to dismiss questions about the audience as we’re developing content or to answer them ourselves. It would be an interesting experiment to see how many times in a day I ask myself something about the audience but move on without getting a real answer. It would be a good habit to stop myself, write down the question, and set about getting answers so I’m not making assumptions about my audience.
Wrap-up
Books have been written on the basic principles of technical writing, but these are two that I’d put right up front. Know your audience to the point that you have the answers to any questions that come up about them, or be willing to find the answers so you don’t risk developing a concept of your audience that’s wrong. We’re information gatherers, and we’re user advocates. We can use the first to reinforce the second.
Related entries (auto-generated):
A Way to Get Technical Writing Practice
A Possible New Step in the Writing Process
The Effect of the Organization’s Culture on Conversational Technical Writing
Journals by Email











Ben Reply:
January 22nd, 2010 at 8:00 am
Haitham, that’s a great idea about the flowchart. Sometimes we struggle with ways to accommodate both the experienced and inexperienced, the savvy and the struggling. A fellow member of my STC chapter said he has implemented a one-thirds/two-thirds layout in some documents, where a column that’s one-third of the width of the page gives the quick instructions, and the other column gives more detail and explanation. I like the simple flowchart concept. Thanks for sharing that. I agree that anyone who interacts with users regularly is a great resource.
[Reply]