How to Prepare a Talk

by Jason Eisner (2015)

Some of my usual tips for students who are designing a technical talk.

A polished talk makes a lasting impression. A weak talk means you just wasted a year doing research that no one will read. Either way, the audience members will draw conclusions about you and your work. The good news is that it's fun to get them excited about your work. The more good talks you design, the easier it becomes, and the more people will come hear you!

It makes me happy and excited to give a talk that is well-crafted and supported by pretty slides. I'm excited not only to share the technical ideas in the talk, but to delight the audience.

Talks vs. Papers

Talks and papers are both forms of teaching. Much of the same advice applies. However, a paper must do double duty as reference material that lets anyone verify your work. Your talk's only obligation is to be clear and entertaining:

In other words, the audience should understand you while you're talking, and your memorable gimmick should help them recover that understanding later.

Rereading your paper is certainly a good start—you worked hard on it and it's a good source of material. You might very well want to organize your talk the same way as your paper. But your talk needn't follow the paper exactly:

Also remember that you'll be talking:

Developing a Presentation Strategy

It's a mistake to start making slides right away. First you need to design the flow of the talk. Don't get bogged down in Powerpoint or Keynote hacking before you know what role each slide will play.

Step 0: Getting perspective. Teaching begins with extracting your head from wherever it's stuck. You are an expert, deeply wrapped up in the problem. Your audience may be as smart as you, but they know so much less, and they're so much less invested! Take a deep breath and prepare to see the work through their eyes.

Step 1: Whiteboarding. Explain your work to a colleague, at a whiteboard. You are improvising, so monitor their reactions! You are looking for a magic incantation or drawing that will make the light bulb go on over their head. It may take several tries. When you hit on an approach you like, write it down. You haven't explained quite everything yet, so figure out how to get the next light bulb on ...

Now explain your work to another colleague. It should be easier this time. You're mostly testing your incantations from last time, but you may also try out some new orders and new ideas.

Step 2: Setting goals. Write down 3 technical things that the audience really needs to understand. Also write down 3 messages that you'd like your audience to take away from the talk. In your talk, you will state these messages explicitly, and you'll also convey them by how you choose examples and allocate time.

Step 3: Outlining. Draft an outline. Regardless of the hierarchical structure, each section should flow naturally into the next.

Step 4: Storyboarding. Get a stack of blank printer paper. Yes, physical paper! Sketch out one slide per page, using colored pens. Slides are just visual aids to support you as you talk. So, talk away, and revise the slides as you go! Paper slides are easy to sketch and annotate, and easy to edit, shuffle, and replace when the sequence isn't working for you. You don't have to spend time drawing small details that you can imagine. However, sometimes you'll want to carefully sketch actual layouts for important diagrams, and write out actual text for titles and bullet points.

Step 5: Slidifying. Once your advisor has given constructive feedback and helped you improve your storyboard, make the electronic slides. Your first pass can leave some details to fill in later. Use Keynote, Powerpoint, or perhaps sfig. I recommend against Beamer or SliTeX (see below). Google Slides allows your collaborators to edit or comment, but has fewer features.

Step 6: Rehearsing alone. Practice the talk with a timer. Do not skip this step! You'll need to run through the talk several times. The first time I run through a 20-minute talk, it usually takes me over an hour, because I am experimenting with different phrasings. When I hit on a clear, concise phrasing, I jot it down (perhaps in the notes attached to the slide). If I can't find a good way to talk about a slide, it's a sign that I need to change the slide deck. Often it means I need to back up and fill in some supporting ideas.

Step 7: Practicing with an audience. After you've rehearsed a bit on your own, deliver your talk to a few colleagues—try to include some newcomers who don't know your work. Get feedback. Revise your story and your slides accordingly. If there's time, give a second practice talk to make sure that the new version works.

Step 8: Final timing. Really polish the talk—stand in front of a mirror when practicing. Make sure it's down to 20 minutes (or whatever) and that you feel comfortable giving it.

In all these steps, you are working toward a clear and entertaining presentation ...

Being Clear

Framing your argument. It's not enough to present a list of true assertions. Think about other fields:

The only way an audience can follow a collection of ideas is if those ideas fill the slots in some narrative structure or argumentation structure. Tell a story!

Choosing an order. The basic problem is to linearize a complicated network of ideas. As I explained in an interview about teaching:

[We experts have] all the formalizations, techniques, and examples in our heads at once, and they're bonded to one another in a dense ball in which everything follows from something else. If we pull on any one idea it just snaps back into place.

But to teach, we have to cut some of those bonds and unfold the structure into some linear presentation that will then fold up correctly again—like a protein—in a student's head.

[Protein design is NP-hard, so heuristic techniques are used. The previous section encouraged similar strategies for talk design—coarse-to-fine search, stochastic local search, birectional search, etc.]

"Oh, just one more thing." One handy type of linear structure is to start with easy stuff, and then tweak the audience's understanding bit by bit. Every few minutes, the audience should feel like the talk is essentially complete—but then you confide that there's one more detail you want to share:

  1. Let me remind you of a beautiful idea in our field. Weren't you happy to see that explained so well?
  2. By the way, that leads to the following new problem ... and here are some sample results. Great!
  3. I led you to believe that I used the obvious approach ... but I lied. Let me demonstrate what goes wrong. Isn't that fascinating?
  4. If you've got a few more minutes, I'll explain why a correct solution exists in this case ... here's the key insight. Great!
  5. That solution took O(n3) time ... even better, here's a way to get it down to O(n log n). Yay!
  6. Ah, yes, I glossed over that one subroutine ... allow me a moment to fill it in. Great!
  7. Oh, and that subroutine called another subroutine ... so we do need this one last trick. Ok, got it!
  8. So, that's an algorithm that works with any feature set ... and by the way, here is the feature set we actually used in our experiments. Great!
  9. You're probably wondering about full results ... here they are. Done!
  10. If you've been paying really careful attention, you might be concerned about X ... so here are some extra experiments.
  11. So long, folks. Although perhaps you're worried about convergence rates? ... well, that's too involved for a 20-minute talk, but the analysis can be found in the paper.

This structure keeps the audience appeased. It doesn't let important questions fester till the end of the talk; it promises at every turn that just a few more minutes of attention will be well rewarded; and it yields a good experience even for audience members who lose the thread before the end. (It's like the inverted pyramid of newspaper writing.)

Pictures and diagrams. Most slides should be pictorial. If you have a lot of text on a slide, replace it with a diagram or animation that communicates the same ideas. You need to figure out how to draw the idea. Concrete examples are your friend here.

Finding the right example. A running example helps to tie the talk together, and it reduces the cognitive burden on the audience. Get the audience engaged early with a concrete problem, and show throughout the talk how each idea acts on that problem. As I've written elsewhere:

Running examples greet the reader like old friends. The [audience] will grasp a point more quickly and completely, and remember it better, when it is applied to a familiar example rather than a new one. So if possible, devise one or two especially nice examples that you can keep revisiting to make a series of points.

Consistency. For the same reasons, you should use a consistent visual language. Choose a few colors and fonts. Specific colors and fonts should consistently mean the same thing—plan this out at the storyboarding step. Your terminology and notation should also be simple and consistent. Reuse graphic elements mercilessly across slides.

Knowing what not to explain. You can't teach everything in the allotted time. If you try, you may end up with a cramped section that no one will understand, unless they're already quite familiar with it. Cut this section and replace it with something higher-level.

Opening strong. The beginning of the talk is special. It has to hook the audience. They're all deeply tempted to "glance" at their email. Make them put those phones away! Convince them that this talk will be (a) interesting, (b) important, (c) fun and easy. They'll listen if they think they're in good hands.

Being Awesome (mandatory)

As you plan out your talk, you should also find a couple of ways to make it awesome! You're performing up there (and building a fan club for your future talks). There are practically no restrictions on what you're allowed to do for the sake of a good show. Your talk should stand out from all of the other talks in the conference.

Have fun and keep your mind open when you're batting presentation ideas around at the whiteboard. If you make a joke or use a goofy metaphor, consider running with it. If you're waving your hands around, is that because you see animated graphs in your head?

The fun stuff does need to support your technical story, not distract from it. It's what people will remember best, so it should be connected to the meat of your talk. The goal is to convey the technical ideas quickly, clearly, and memorably.

You

Here are some ideas:

An admission: This webpage is pretty clear, but I forgot to plan any awesomeness and now it's too late. (It's also all texty bullet points—good thing it's not a talk!)

Avoiding Common Mistakes

There's lots of advice on the web about slide design. Search it, but here are a few basic rules of thumb.

Delivering the Talk

Arrive early. Tell the session chair how to pronounce your name, confirm how you'll be timed, and check the A/V equipment.

Memorize your first few sentences so that you'll be able to ease into the flow even if you're nervous or distracted. Keep a good pace, but stay relaxed and positive.

Listen to yourself talk, and pay attention to audience reaction, which will alert you if you misspoke. If you get a clarification question, don't automatically answer what they asked: figure out where they're confused and answer that.

Questions at the end give valuable feedback. They keep the event interesting and show that the audience is engaged. Again, listen to the question, think before answering, and stay positive. In a longer talk, it's nice if you can pause periodically for questions, or let the audience know that you don't mind being interrupted.

Hopefully it won't go as envisioned in PhD Comics:


This page online: http://cs.jhu.edu/~jason/advice/how-to-give-a-talk.html
Jason Eisner - jason@cs.jhu.edu (suggestions welcome) Last Mod $Date: 2017/01/25 05:52:56 $