Just Say It: 3 Easy Tips for Communicating In Plain Language

Great post Joe! I’ve got that same George Bernard Shaw quote hanging in my cube! It is so true.

Congratulations on being a “Featured Blogger” – good to see the Minnesota perspective being represented!

Plain language is *sometimes*, but not always, the same thing as a clear explanation. Not that clear explanations *shouldn’t* use plain language, but often one can follow every conceivable tip for making language plainer, and things still aren’t any clearer. The sad reality is that very few of us, no matter how far up the educational ladder we go, receive any sort of formal instruction on *explaining*. If you’ve ever had to grade undergraduate exams or essays, you’ll know just how prevalent that shortcoming is in society.

Some years back, I was tasked with teaching a community college class comprised largely of computer science students. I won’t go into the overall curriculum, but in an effort to rectify the dearth of training students get in explaining, one of the modules I incorporated was on writing documentation. It was prompted by a talk I attended given by eminent text-comprehension authority Walter Kintsch ( http://psych.colorado.edu/~wkintsch/ ). During his talk, Kintsch noted that he had shortly-before had reason to consult the documentation for a piece of software purchased some years earlier. Much to his surprise, and in contrast with what he often heard others complain about, he found it to be quite well-written. BUT, he noted, it was written from the perspective of an expert, anticipating the moment-to-moment information needs of an expert. And that is sort of the perpetual challenge of writing explanations, instructions, or documentation for anything we have been a little too close to for a little too long. We think in terms of what WE know and anticipate; having a much harder time anticipating what the novice is thinking and expecting. (Hence the origins of the various “For Dummies…” and “Complete Idiot’s Guide” series, that attribute comprehension failure to the learner, instead of the writer, where such blame properly lies.)

Armed with that insight, I brought a video projector to class so that we could collaboratively write documentation. I selected something that everybody in the class knew extremely well, and would have a hard time “de-experting” themselves from. One year we wrote instructions for how to play Monopoly, and the next year we did Scrabble. The assumption was that they were writing for someone who knew a bit about board games, but had never played either of the two mentioned. To be frank, it was hard work for them. The hardest part was restraining themselves from wanting to race ahead to the complex fancy stuff. I had to keep asking them constantly “Does the beginning player want or need to know that right now?”, “What question are they likely to have at the moment?”, “Would that information be of more value to them if you held off for a bit?”.

And often, those sorts of questions make the difference between something being plain and unclear, or plain and clear. Imagining what the reader wants to *know*, rather than thinking about what you want to tell them, can make a huge difference in your writing. I suspect a useful exercise for nearly any sort of expository writing is to first approach it as if you were constructing an FAQ document. One can then generate a list of information needs of the typical anticipated reader, and sequence those questions in the order that you think they might crop up in the reader’s mind. By presenting the information in a sequence dictated by the reader’s moment-to-moment information needs, it will make far more sense to them. Of course, don’t forget to keep your language simple.