Let’s discuss how to tie a tie. First, you take the tie and put it around your neck, making sure that it lies within your shirt collar. Make sure the seam is facing toward your body, and the wider end of the tie hangs down roughly two-thirds of the length of the tie. In other words, the wider end should hang down farther than the narrower end. Take the larger end over the narrower end. Wrap it around once so that it forms a knot. Take the larger end and put it through the knot you created. Once that’s done, pull it tight. Adjust your tie by pulling on the narrow end, which should now be behind the wide end. Your tie should now appear neat and flush against your shirt.
Raise your hand if you actually followed the above paragraph. And when I say “followed,” I mean that you read (as opposed to skimmed) through the entire paragraph, following every step and not falling asleep while reading it. I’ll bet that not a lot of hands are up.
Yet this is exactly the way that so many technologists tend to write when they are asked to convey a set of instructions. They will write (or talk) in lengthy detail, explaining every little thing and believing that the reader (or listener) is soaking up every detail and is in rapt fascination of the subject, holding on to every single word.
Oh, if only that was true. If that was the case, we wouldn’t have technical writers.
I wrote a couple of articles a while back about tech writing frustration and why design matters. They provide some thoughts that are directly related to this article, so I suggest you read them before continuing with this article. If you haven’t read them yet, check them out. Go ahead. I’ll wait.
At this point, I’m trusting that you understand at least some of the principles behind good writing and design. (If you don’t, and you didn’t read those previous articles, shame on you.) Many, if not all, of them come into play when talking about talking to a non-technical audience.
Giving (and taking) instructions is hard
Let’s talk about that initial tie instruction paragraph for a moment.
This is a demo I use in two of my presentations. I ask for a volunteer, preferably someone who does not know how to tie a tie. I hand him or her a tie, and give that person simple instructions: “put it on.” Of course, if the person doesn’t know how to put on a tie, he or she is likely to struggle doing so.
At that point, I get the rest of the audience involved. My instructions to the rest of the group: “you folks are the help desk. Tell this person how to put on the tie!”
I’ve done this demo to varying degrees of success. In some cases, the audience does a very good job of explaining how to tie the tie, and it ends up looking pretty good. I’ve also seen demos where my volunteer looks like he or she tried to tie the tie using only one hand, two fingers, and blindfolded.
The point of this exercise is to demonstrate that giving and receiving direction is difficult. A lot of people mock tech writers, thinking that writing step-by-step instructions is no big deal. But after putting people through this exercise, they usually end up singing a different tune.
When you’re talking to a non-technical audience, patience is a vital virtue. People can be intimidated by technology, and lack of patience on your part will only do more to add to their discomfort. Bear in mind that your audience is not as tech-savvy as you are, and will likely not have a grasp of technological concepts.
Any time you try to do a task you’ve never done before, how do you feel? Most likely, you’re going to be at least a little nervous. These people are likely to feel the same way. Telling them to “click Enter” might as well be telling them to hit the gas pedal while they’re blindfolded.
Speaking of clicking Enter, don’t take for granted that people might not know what some technologies are. I’ve heard stories of people using mice to different degrees, including using them as foot pedals and holding them up to the screen. (And by the way, I’m sure you’ve heard the joke about not being able to find the “any” key. I can tell you from firsthand experience that those are not jokes — the stories are true!)
What you see may not be what the audience sees
I’m sure you’ve seen the classic image below.
What did you see first: a vase or two faces? Perspectives matter, and it happens all the time when trying to explain technical concepts. Don’t assume that your audience sees the same thing that you are. Even if you and your audience are looking at the same screen, what you and your audience see might not be the same thing.
Having said that…
A picture is worth a thousand words.
Very early in my professional career, I was tasked with writing a document for the nighttime support staff, explaining how to support a WORM drive. When a customer requested data from an optical platter that was not in the drive, the user needed to insert the new platter into the drive. I could have written an instruction saying that the A side had to be up, with the A label on the left edge, and the disk slide facing away from you as you put it in the drive.
Instead, I opened my very primitive paint program and drew something similar to this:
Suddenly, the instructions were clear. The document was successful, and the operators were able to follow it to perfection.
However, be careful — there is a wrong way to use illustrations! Imagine, for example, that you’re trying to find a Little Caesar’s Pizza or a Home Depot. You find a site that has a map. The problem is, the map is an image that’s zoomed in (with no way to expand the map). The image looks like this:
Tell me, on what street are these places? For that matter, in what city, state, or even country are these located? There’s no way to tell, because there is absolutely no point of reference or context to this illustration. A picture might be worth a thousand words, but if you’re not careful, it could be worth exactly zero words.
I once sat in on a SQL Saturday presentation by Thomas Grohser where he was talking about SQL data storage systems and data access. I’ll admit that I had a hard time following some of what he was saying, until he gave the following analogy:
“Imagine you get on an elevator with ten people. Each person presses a different button. Now imagine that the elevator has to go to every floor in the order that the buttons were pushed!”
Suddenly, Thomas’s concept was crystal clear!
Another time, I was speaking to a co-worker who had tried to explain to someone that she was trying to store more data on a disk than there was space on the disk. (This person did not understand that data takes up disk space.) I told him, “you should’ve said that you can’t put ten pounds of stuff* into a five pound bag!”
(*Okay, I didn’t say “stuff!”)
The moral of the story is that analogies are highly effective in communicating concepts. If you can effectively explain a concept using an analogy (note: make sure the analogy you’re using is business-appropriate), then go ahead and do so.
KISS! KISS! KISS!!!
No, I don’t mean hanging out with your sweetheart.
Make sure you follow the KISS principle: KEEP IT SIMPLE, STUPID!
Technical instructions need to be kept simple. A lot of technologists don’t understand that reading is work! It takes work to read and comprehend a paragraph. What if a set of instructions needs to be understood quickly? If a person needs to take a minute to figure out what is being said, that’s a minute that was just wasted.
Generally, the rule of thumb I use is, if it takes more than a few seconds for a reader to understand my instruction, then my instruction has failed. Don’t make the reader have to work.
Realize that this will not happen overnight
Now that I’ve gone through some of the suggestions for talking to non-technical people, understand that not everyone has the ability to convey technical information in a manner that can be understood, and being able to do so won’t happen overnight. Like everything else, it takes time and practice to get that skill down.
In any case, hopefully, these tips will help you become a better technical communicator. In the long run, this ability will enhance your skill set — not just as a communicator, but as a technologist as well.