Long ago (1988) I moved to Berkeley and started sending a monthly "newsletter" to my Boston friends. When I returned to Boston (1993), I continued the tradition for about five more years (or until I had kids). Looking back, I realize that I was actually blogging. Each newsletter contained anywhere from a few to several blog posts. Having been silent for the past decade or so, I've decided to resume these activities. Don't expect anything profound -- I tend to focus on what I find entertaining or amusing and perhaps sometimes informative. We shall see!

Monday, July 10, 2023

How to Present your Research: Part 6: Common Presentation Pitfalls to Avoid

In our communication skills group last week, the student presented (for the first time in this group) work-in-progress talks or a 3-5 minute research summary. I try to give everyone detailed feedback, but there are common things that came up, so I figured I'd try to write them down here. This post could really be called "Tips for Presenters."

1. Timing

The assignment was to prepare and deliver 3-5 minute presentation for a generation audience (i.e., not your project team, but a group of smart computer scientists). I then asked each person how long they thought their talk would go before they gave it and then how long they thought it actually went. I timed all the talks.

Unsurprising, practically every presentation went longer than expected. Similarly, everyone knew they'd gone longer than they expected, but they were not super accurate at realizing how long they went. And this is 100% normal on both cases. Our ability to judge how long it is going to take to present material is not particularly good.  The problem is that while a 3 minute talk might run over by a minute and that doesn't seem bad, proportionally, that means your 20 minute talk just became a 26 or 27 minute talk and that's actually a real problem!

Why do we underestimate? (There is likely science on this, but I'm going to draw on my experience here; it would be interesting to compare my experience and assessment with the literature, but I don't have time to do that now, so we'll leave it for a future post.)

I think there are three main reasons: 1) We think more quickly than we speak, so unless we practice the talk out loud, our timing is off, 2) If we practice without an audience, we have no feedback about whether what we're saying is getting through -- when you have an audience, you are getting feedback and that almost always results in your slowing down, 3) We have an inherent fear of running out of things to say, so we over plan.

Just like we read more quickly than we speak, we also think more quickly.  So, if you practice your talk by going through it in your head, your practice will not match your delivery. The solution to this is simple: practice out loud. I hear you, "Oh that's so cringy."  Yes, it really is. Do it anyway.

Similarly, do a real practice talk in front of real people. You clearly are not going to do this for every status report, but when you are presenting for real, do a practice talk. This will be the best way to see how long your talk is going and to check whether you and your material are in sync and conveying the key things you want to convey. And then ask for and gracefully accept constructive feedback. You then get to be judicious in how you incorporate that feedback, but while it's being given, I encourage you to follow the Gotham Booth approach and simply listen, take notes, and ask clarifying questions, e.g., "Was it the graph you found confusing or how I described it?"

Now, how do you conquer that internal dialog that goes something like this, "You know, there is nothing particularly deep here. You're going to be done in two minutes and everyone will think that what you did is simply no big deal." How did I know that's what you were thinking?  Because we all go through that dialog to differing degrees. My advice is to keep the presentation itself streamlined -- explain things clearly and in ways that connect. When you are tempted to off on a digression about some fascinating detail, make a set of backup slides. I don't know how long powerpoint has had "sections," but now that they do, sections are a great way to organize various sets of backup slides. You have them in case someone asks the question (and won't you look so awesomely prescient when you pull them up!), but you can avoid embedding the digressions and extra detail in the talk.  And, the sheer existence of the backup slides should help qualm that annoying little demon who tries to convince you that you have nothing to say.

2. Matching Delivery Rate to Absorption Rate

For longer than I care to admit, I could not exactly figure out why I was uncomfortable with one of my former students who always wrote out their talks completely in their speaker notes. I too sometimes write out what I'm going to say, but I absolutely never actually read what I write while giving the talk, so why did it bother me so much when this student wrote out what they wanted to say? It took me a couple of practice talks to figure it out.

If you read your talk (and aren't excruciatingly careful), you are able to deliver your talk at a rate that is faster than the rate at which your audience can absorb it.  This sounds obvious in retrospect, but only in retrospect. When you are simply reading the words you want to say, you aren't pausing and stopping to allow your audience to keep up with you. When you do not have a written script (and haven't memorized your talk, which is equally problematic), then you tend to pause at the right places, and since you have to think a bit about what you are going to say next, you give your audience time to internalize what you've just said.

Therefore, I advise writing notes/bullets to yourself in your speaker slides (I find numbered points particularly helpful and try to avoid having more than about 3 points I want to make on any slide; a point can require multiple sentences). Think of these are reminders of the topics to cover, but not the exact words, so that you have to engage in a thinking process (not a reading process) when you speak.

If you really really really don't want to have to select words on the fly (and I completely understand many reasons why you might not), then you should 1) repeat the words, "Slow Down" in your brain at the beginning of absolutely every slide and 2) insert <pause> in the right places in your talk,  where you need to stop and give listeners a chance to catch up. I also insert <click> when I want to sequence through animation on a slide.

Pacing your words to keep your listeners engaged is perhaps that most challenging part of giving a talk, and it requires a lot of practice!

3. Buzzword Bingo (this is really about clarity)

There are few things as frustrating as being in a talk and having the speaker toss out terms and acronyms that you don't understand. (My department is terrible at this and when I first joined, I spent every faculty meeting raising my hand and asking what every acronym meant.)

So, nearly all acronyms should be explaind on first use (you can assume everyone knows what a CPU is; you cannot assume that everyone knows what a BANANA -- yes that's an acronym, but not in CS: Build Absolutely Nothing Anywhere Near Anything). In general, avoid inventing acroynms just to make your life easier (I have had students in the past who would introduce 10-20 acronyms in the introduction just to avoid having to type words out later in the paper; this is not a winning strategy for getting papers accepted). I like to think of writing and reading as a give and take process. Every time, you ask your reader to learn something to read the rest of your paper (i.e., what BANANA means), you are taking. Before you take, you'd better give them something pretty darned special to have them be willing to give you the effor to learn your acronym. After being forced to learn about three new acronyms, I am pretty grumpy reading the rest of the paper.

If you find yourself explaining some term and never using it again; don't use it; just explain what you're doing that one place you're tempted to introduce it.

Assume you are talking to a non-expert and define/explain every term that a non-expert is unlikely to know. Ask yourself, "Did I know what this term meant before working on this project?" If the answer is no, then chance are you need to explain it during your talk.  And, the more time you spend explaining terms, the less time you have to discuss things that are truly interesting.

Take Aways

  1. Practice your talk out loud.
  2. Give a practice talk (and invite a range of people who can give you feedback from different perspectives).
  3. Keep the maintalk streamlined and have backup slides (material).
  4. Match your delivery tempo to the absorption rate of your audience. This requires careful and thoughful pauses in your speech.
  5. Keep acronyms to a minimum.
  6. Define all terms specific to your area that are unlikely to be understood by those not in your field.

No comments:

Post a Comment