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:

• Clear. Give your audience that "aha!" moment of understanding. They should be able to tell their friends exactly what your key idea was.

• Entertaining. Your audience should remember your talk for at least a year, so that they'll read or recommend your paper when it is relevant. To lodge in their mind, you gotta get a gimmick. A conference has so many talks that most are quickly forgotten: but not yours!

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:

• It won't cover everything in the paper. (It's just an advertisement.)
• It might include material from outside the paper. (You could spend a little time teaching background concepts, or advertising other related papers of yours.)
• It might complement the paper by explaining things from a different angle. (Your personal website will link to your slides along with your paper.)

Also remember that you'll be talking:

• A talk audience has to keep up with your pace.
  • So it's especially important to be example-driven and convey intuitions.
  • A writer may connect ideas with just a few words: "Although A, B." In talking, you need to sustain a point or people will miss it: "You might think A. But actually what's more important is B, and here's why."
  • This is not an excuse to ramble. Your audience can't skim the boring parts of your talk any more than they can reread the hard parts. They have to endure your words at the rate at which you utter them. So choose them carefully.
• Spoken language differs from written language.
  • So to prepare your talk, don't write and then recite what you wrote. Do the opposite: speak and then jot down what you said!
  • You can make use of intonation, and you can be more informal. (E.g, how can you get someone engaged with your question? Ask the question explicitly, then answer it.)
  • Audience participation is possible. E.g., ask your audience to guess something: call on someone or have everyone vote. Then make the answer appear.

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:

• Law. That's not how a lawyer convinces a jury. A lawyer has to frame the facts, telling a story that ties them together.
• Politics. Such a story is crucial. As any political scientist can tell you, each voter will forget "inconvenient" facts that don't fit their narrative of society and the candidates. You don't want your audience forgetting your points, so tie each point into the narrative arc.
• Math. Listing justified assertions isn't how a mathematician convinces a reader that a theorem is true. Even if the assertions add up logically to a proof, no one will be able to understand or remember a disorganized proof, or derive insight from it. A really well-structured proof describes the process of coming to understand that the theorem is true. It tells a plausible story (perhaps cleaner than the historically accurate story) about how someone might have developed the proof on their own. For a complicated proof, this may include stops along the way at motivating examples, inspirations from other theorems, lemmas, incorrect versions of the theorem, and counterexamples.
• Business. Every startup founder has an origin story, which explains the idea and its importance by describing how it (supposedly) got hatched.

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(n³) 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.

Here's a short video on how to design an intro that will hook your audience, as well as a Twitter thread on how to wrap up the talk at the end.

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. Here are some ideas:

• Metaphors / analogies. An analogy builds on something your audience already understands. Many good analogies are entertainingly whimsical and can resonate through your talk, guiding your choice of examples and clip art. My talks as a grad student used fruit trees, stacks of hats, Communist revolutionaries, asylums, ... I still love analogies!

• Stories. Can you motivate your problem, or describe your solution, by constructing a fable? Everyone loves stories about Alice and Bob (who may be users, computational processes, bemused students, competing terms of an objective function, Lewis Carroll characters ...). True stories can also be compelling.

• Aphorisms. Can you boil an important idea down to a pithy catchphrase? Put it in big type on its own slide, and keep coming back to it!

• Algorithm animations. You may be able to programmatically generate an animation of your algorithm. If that's too hard, you can do a mockup using your presentation software's animation features.

• Physical props. When did our community agree to stare at a projection screen all afternoon? If you have a physical analogy or a story, bring objects and manipulate them in front of the audience!

• Confederates. No one said that a talk has to be a solo affair. Two speakers can give a talk jointly, perhaps even staging a skit where one is questioning or challenging the other. You can also plant someone in the audience.

• Photos, videos, clip art. Some talks stand out as strongly visual. The web is full of images. It's also easy these days to take your own photos or videos, or perhaps you can draw or commission cartoons.

• Audience participation. If you ask the audience to guess something, it's instant engagement. Your question should be neither intimidating nor obvious, so that people want to answer. You can call on a couple of people or do a show of hands. Then reveal the actual answer.

• Wit. Throwing in some little jokes along the way keeps the audience's attention and energy up.

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.

• Timing. Standard advice is 20 slides for a 20-minute talk.

  • You may be able to get away with 30+, if you are disciplined about keeping the slides simple.
  • Multiple slides might count as a single slide if they effectively form an animation sequence.
  • Remember that your audience needs time to decode each slide. When you show bullet points, you may have to read them out loud. When you show an unfamiliar graph, you'd better point out the axis labels and talk through the legend.

• Layout. Don't be cramped, cluttered, or wordy.

  • Use the full screen. For a technical talk, you don't need a slide template with borders and background graphics. A plain white (or black) background gives you more flexibility.
  • Don't be tempted to fill all the space. Keep the layout simple and open. One idea per slide, unless multiple ideas need to be shown side-by-side. Split a cluttered slide into multiple slides. Or animate it, with material appearing and disappearing.
  • Streamline the text. Keep bullet points short, or replace them with diagrams. People can't listen to you talk about something else while they're reading your bullet points.
  • Keep animation simple and relevant. Just make elements quietly appear as you talk about them, or quietly disappear to declutter the slide. Motion is a powerful tool when used sparingly. It is best used in cases where it actually enhances understanding—typically by showing change (evolution of a data structure, improvement in a graph, flow of information, etc.).
  • I recommend against Beamer or SliTeX, which drives most folks to use too many bullet points. You should be thinking in terms of beautiful layout and animation. TeX's automatic document layout is really no substitute for being able to drag things around on a canvas. (Ask me how to easily include TeX formulas in Powerpoint ...)

• Accessibility. Be considerate of your audience.

  • Readable sizes. 24+ point sizes for most text. (Some people say 28+ point.) Occasional use of 20-point is okay for details, axis labels, annotations, etc.
  • Readable fonts. Sans-serif fonts are best for slides. Candara is nice and widely installed, but you can download many others.
  • Slide numbers. Including these lets the audience refer to particular slides at question time.
  • Contrasting colors. (That said, it's nice to pick colors that have similar saturation levels, i.e., intense colors or pastel colors.) Where color contrast is semantically important, avoid using red vs. green because some audience members may be color-blind.
  • Consistency. Use a consistent visual language, as already discussed.
  • Persistence. You'll be putting the slides online. So make them interpretable on their own, or add speaker notes or a screencast to the online version.
  • Audience modeling. Be aware of the range of backgrounds in your audience. Be very alert to misimpressions that people might get, and try to head them off.
  • Here's some advice from ACL about designing and delivering accessible presentations.

• Emphasize the organization and the main message.

  • Highlight key words and key points.
  • Make clear which bullet points are good versus bad news. Which ones are definitions? Which ones are surprising?
  • If there's a complicated formula, table, or graph, label its parts with big friendly colorful labels. You can also animate it to appear bit by bit.
  • Break down the talk structure with periodic section-title slides, or "you are here" slides that show the current position in the outline. Also highlight the structure with your spoken words: "Tell 'em what you're gonna tell 'em, then tell 'em, then tell 'em what you told 'em."
  • Use strong slide titles. "Experiment" is weak, vague, and contributes nothing. "3x Speedup from Adaptive Stepsize" is a strong summary.
  • Consider putting an explicit "takeaway message" at the bottom of every slide.
  • Keep coming back to the big picture. Avoid a chronological narrative of "we did X, we did Y." Instead give the principles that forced you to do those things, and note where the choices were.

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:

Improving Over Time

Everything gets better with practice. Over time, you'll learn to spot problems with a talk design, and you'll accumulate a bag of tricks for solving these problems.

A cheap way to practice: Pay attention to the design and presentation of other people's talks. Some speakers are great at laying out a complex idea and engaging you along the way. Try to figure out how they did it. Conversely, if you're in a talk that is boring or hard to understand, you can still get something out of it— shift your attention to diagnosing the problem. That's actually how I learned how to teach: I had some bad teachers, and came away with a list of things to do differently.