Photo credit: Lee-Ann Thompson
A slide is not a document.
Creating slides for your presentation and writing a supporting document (such as the takeaway handout) are two different things. Yes, I know. This is obvious. But how many people do you know who make a "handout" for their presentation by printing out their slides (six slides per page)?
When we attempt to "kill two birds with one stone" and generate slides that will also serve as handouts or a "document," we often end up with dreadful supporting slides for the talk and ambiguous, ineffective handouts for the takeaway document. Two weeks after the presentation these papers — with their promising coversheets but filled with small images of bulletpoint slides — can be painful to "read" (if they are ever read at all).
Author John Scalzi offers good writing tips for professionals who are not necessarily professional writers. The article is short, sweet, and excellent. If you have time, there are some good nuggets of wisdom in the comments section as well, currently at 146! (The exclamation mark proves, I suppose, what a hack writer I am. My apologies.)
OK. So the creation of presentation visuals, the delivery of a talk, and the writing of supporting documents are different animals.
But there are some commonsense principles which apply to writing and presenting. A few of Scalzi's writing tips (listed in bold below), can be applied to the art of presenting as well. Here are four from his list of ten tips.
1) "Front-load your point."
Make your point, then make your case. You do not want your audience (or your reader) saying to themselves "Where the @#&^%! is this going!?"
2) "Don't use words you don't really know."
Sometimes people use big words to impress or sound credible or smart, etc. Whether it's writing or speaking, never try to impress. When we try to impress, we are thinking about ourselves and not about our audience. We must speak in a style that is natural, conversational, free of jargon, and clear. For example, instead of "I suffered a massive, humongous intel failure" how about "I screwed up"? (The level of your informality, of course, depends on your unique situation.)
3) "Read people who write well."
I "learned jazz" by listening to and watching great jazz players. We can learn how to be a better presenters, in part, by watching and studying the famous and not-so-famous accomplished speakers and presenters of today and the past.
4) "When in doubt, simplify."
Worried you're not using the right words? Use simpler words. Worried that your sentence isn't clear? Make a simpler sentence. Worried that people won't see your point? Make your point simpler. Nearly every writing problem you have can be solved by making things simpler.
This should be obvious, but people don't like hearing it because there's the assumption that simple = stupid. But it's not true; indeed, I find from personal experience that the stupidest writers are the ones whose writing is positively baroque in form. All that compensating, you know. Besides, I'm not telling you to boil everything down to "see spot run" simplicity. I am telling you to make it so people can get what you're trying to say.
About the author:
Garr Reynolds, who lives in Osaka, Japan, is the former Manager of Worldwide User Group Relations at Apple Computer, Inc. in Silicon Valley. With Apple, Reynolds worked with brand communities in the U.S. and Japan and traveled extensively delivering presentations, software demos, and keynote addresses to the firm's most loyal customers. A communications specialist originally from the USA, Reynolds is currently Associate Professor of Management at Kansai Gaidai University where he teaches Marketing. Garr also maintains Presentation Zen a unique site on professional presentation design. His associated blog offers insights that go far beyond the usual PowerPoint tips. Communication officers, business managers and academics will all gain some valuable knowledge from following Garr Reynolds writings and useful pointers.
Also of interest Garr Reynolds' micro-guide to effective presentation delivery.
