Course overview Planning


There are a few fundamental things to understand before you start the course. They come back again and again as you study. Remember them when you write.


Good techical writing

Two images of Ahsoka. One looks disapproving beside the text 'Good technical writing follows all the rules'. The other looks approving beside the text 'Good technical writing communicates with the audience.'

In secondary school, your teachers probably taught you lots of grammar rules, and graded you on how well you followed them.

But now you’re in the real world, and the goal of writing is no longer to get good grades. Writing is a tool, the means to an end. And that end is getting information from your brain into your reader’s brain.

Good technical writing is writing that communicates.


Rule Zero

Image of a skull and crossbones
"Text: 'Most writing advice is what you’d call GUIDELINES rather than actual RULES

So if good technical writing is writing that communicates, can we just throw away all the rules?

Not so fast.

Writing rules exist for a reason. You’ll find that writing that communicates to your readers is more likely to follow the rules than than to break them. But there are times when the rules get in the way. (Some of them are covered in this course.)

If you have to choose between communicating with your audience and sticking to the rules, break the rules. They’re really just guidelines.


Cognitive load

Cognitive load is probably the most important concept in technical writing. It’s basically the work our readers have to do to learn from what we’ve written.

The mental effort required to learn new information

Image of a measuring cup with three different layers. Each of them corresponds to one kind of cognitive load. Reading from the bottom, they are: Germane CL, Intrinsic CL, and Extraneous CL

(John Sweller, 1988, image via Wikipeda)

As technical writers, there’s nothing we can do about the two bottom layers of the diagram. They’re determined by the subject we’re discussing and the nature of the human brain. We can only control the top level, extraneous cognitive load: the load imposed by how we present information.

Most technical writing rules are just well-tried ways of reducing extraneous cognitive load as much as possible, for as many people as possible. Because people are different, you can’t make things easy for everyone. There is no perfect solution, just a lot of judgment calls.

(You can, however, make it difficult for everyone. Don’t.)


Cognitive styles

Different people think differently.

Verbal thinkers

"Please explain what you want me to do."

Visual thinkers

Image of a puzzled person taken from IKEA build instructions.

Cognitive styles are the reason you can’t reduce everyone’s extraneous cognitive load to zero. Some people absorb verbal information best and just want you to tell them what they need to know. Others learn through pictures and diagrams, and find words tiring.

IKEA instructions are the perfect litmus test: some people find them delightfully clear. Others can’t make head or tail of them.

Both kinds of people are first class citizens of your information. Where possible, find ways to cater to both of them. This course focuses on technical writing but you should also include visual elements in your documentation. Note that the images shouldn’t just be decoration. They have to strike to the heart of what you’re explaining.


Style guides

Image of different men’s hairstyles from the 1950’s.

Writing style guides are tools to make your writing consistent with the people you work with. That way the documentation doesn’t have distracting changes in voice and style. Style guides explain how to write, how to format different types of text, and even how to spell and punctuate common technical terms (wifi? WiFi? Wi-Fi?).

This course follows to the Google Developer Documentation Style Guide. The guide itself has more details and examples.

Ask if your organization/project has a style guide. If it does, and that guide disagrees with anything in this course, follow the guide rather than the course. If your organization/project doesn’t have a style guide, it’s time to adopt one.


Course overview Planning