“Everything should be made as simple as possible, but not simpler.”
— Albert Einstein
“If you can’t explain it to a six year old, you don’t understand it yourself.”
— also supposedly by Albert Einstein
If you’re on Facebook, I’m sure that you’ve seen the memes that go something like this: “tell a sad/scary/happy (whatever) story using only four words.” It’s hard to do, isn’t it?
Welcome to the world of technical communication. One communication tenet that I constantly preach — and you’ll hear me talk about this time and again in my presentations — is the KISS principle: “Keep It Simple, Stupid.” Ask anyone involved with technical writing, documentation, or professional communication, and I’ll bet that most, if not all, of them will mention the KISS principle in some way, shape, or form (maybe not in those exact words, but you get the idea). The goal of communication, after all, is to transmit information from a sender to a receiver. If the message being conveyed is easy enough for the receiver to understand, so much the better.
However, here’s the irony: making things simple is difficult!
How often have you been asked to write something for knowledge transfer, and ended up with something that was nearly incomprehensible? (Don’t be afraid to admit it; hey, I’ve done that, too!) Whenever we’re tasked with writing documentation, our tendency is to explain every little tidbit of knowledge that’s in our head. When that happens, we end up writing a huge paragraph of black text that nobody — and I mean, NOBODY, including yourself — wants to read! That is not conveying information; that is obfuscation.
So how do we go about making things simpler? For starters, I discuss some ideas in my previous articles about design, document frustration, using examples, and talking to non-technical people. I won’t rehash them here; I’ll leave it to you to go back to read those articles.
Additionally, here are some more thoughts that might be helpful.
- Include only information necessary for the task at hand. Avoid the tendency to include every last detail. As a former manager was once fond of telling me, “don’t tell me how to build the clock; just tell me what time it is!” I also remember a time back when my father was first learning about PCs. He kept asking me questions about how the CPU and memory worked. I finally said in frustration, “you don’t have to know how an internal combustion engine works in order to drive a car!”
- Put yourself in the reader’s shoes. When I wrote one of my very first technical documents, I said to myself, “okay, let’s say I’m the night operator who needs to use this document. What do I want to see that would help me?” That mindset resulted in a very successful document. Reader empathy goes a long way.
- I’ve said it before, and it’s an old but true saying: a picture is worth a thousand words. A good illustration can convey a concept that’s difficult to do in words.
- Avoid using long (or multiple) words when a simple (or single) word will do. I think this is self-explanatory.
- Voice matters. Below are two sentences, one using active voice and one using passive voice. Question: which one is easier to read? Advice: try sticking to active voice.
- Active: “John mowed the lawn.”
- Passive: “The lawn was mowed by John.”
- Formatting is a big deal. Check out documents that you found easy to follow. Pay particular attention to paragraph length, whitespace, headings, and so on.
People — myself included — say that the easier you can make things, the better. The fact is, we humans only have a limited attention span, and we neither have the time nor the patience to comprehend complex information. Simplifying things helps — but it’s also hard to do. If you ever believe you know a lot about a concept, try explaining it to a child — and see for yourself how easy it is.