Advice for New Speakers

Giving a good public presentation about your research is not easy. It takes practice to develop the skills to communicate your work clearly, particularly for a general computer science audience. This document provides some suggestions for new speakers based on what we've learned -- both from experience and from other people -- about giving good talks. The style described here is not the only right way to give a talk, but it is one way that works.

For better or worse, the use of PowerPoint or OpenOffice for computer science presentations has become very common. The suggestions below are geared towards talks presented with such tools. Our advice takes the form of a list of common problems that plague inexperienced (and also experienced!) speakers.

Problems with slides

  1. Too many slides. For a talk of N minutes, aim for a little fewer than N slides. (For example, aim for 15-18 slides for 20-25 minutes, and do not expect to cover more than 23-25 slides.) With too many slides, you risk rushing through slides or not finishing your talk on time.
  2. Slides that are too dense. With slides, less is more. If your slides are simple and easy to read, your audience will be more inclined to read them. A good rule of thumb is no more than three bullet points pet slide, each with at most 2 lines of text (less if the material is important). A more extreme version of this rule that is sometimes offered is "at most 3 points, at most 5 words per point." One way to make a talk less dense is to make effective use of figures. Ask yourself: how many slides has it been since my last figure? Am I trying to describe in text a concept that would better be shown visually?
  3. Slides with material that is not discussed. This is related to the previous problem. Never put text (especially math!) on your slides that you do not expect your audience to understand. It is frequently better to avoid detailed technical points in favor of providing your audience with a better intuitive understanding of your work. If you must put math on your slides, the best thing to do is simplify it as much as possible and walk through it carefully. It is sometimes desirable to put math on slides to preempt questions from expert listeners, but you are still responsible for explaining in words what the math says to the rest of the audience.
  4. Bad graphs. If your talk involves graphs or charts, make sure you explain carefully how to read the graph, and what high-level point it is intended to make. There's no point in putting up graphs if no one can read them or understand how they support your claims. In particular, always make clear what your axes represent.
  5. Tiny fonts. Use large fonts. Your audience will be happier if they can read your slides without squinting. Larger fonts also force you to cut down the amount of verbiage on your slides. Sizes less than 24 points are usually unsuitable for any text in a PowerPoint presentation; for bullet points, don't go below 28-30 point fonts.

Advice about organization

  1. Clearly state the problem you are solving. On a single slide (possibly titled "The problem to be solved" or something else very explicit), state exactly what problem you are solving. Unless your audience understands the problem early on, they will be largely unable to follow your solution. Computer science audiences in particular like to see crisp, well-defined problem statements.
  2. Clearly distinguish your contributions. Most talks begin with some explanation of background and related work. You should make very sure that your audience knows where the background ends and your contributions begin. It can be very helpful to have a single slide summarizing your contributions. Depending on how important it is to impress your audience with these contributions, you may wish to display this slide more than once (e.g. once at the beginning and once at the end of your talk). A related point: try to limit your discussion of background to no more than about 1/3 of the talk if possible.
  3. Define all technical terms. Try to limit the number of new concepts or acronyms you use that would not be common knowledge to a general CS audience. For those crucial terms or abbreviations that you must include in your talk, define them explicitly on a slide.
  4. Include redundancy in your talk. We all know the value of redundancy for correcting errors in network communication. It has the same value in giving talks! If you define a term (as in the previous point), say the definition again the first few times you use it. This helps people recover in case they were not paying attention (or came in late) when you defined the term the first time.
  5. Use an outline slide. It's very common for talks to use repeatedly a single slide that serves as an outline. A speaker usually displays this slide near the beginning of her talk to give a broad overview of what the talk will discuss. She then breaks the talk into the sections described on the outline slide and, at the start of each section, flashes up that slide to remind the audience of what comes next. For short talks, this strategy may be overkill, but for longer talks (25 minutes or more), it helps listeners to synchronize with the talk structure and to recover if they've gotten lost.

Problems with delivery

In an age that has forgotten how to deliver public speeches, delivery can be one of the hardest parts of a talk to get right. These days, the bar for delivery is pretty low, since not many people are good speakers. However, if you learn to deliver consistently good talks and practice often, you will be a star when it comes time for conferences and job interviews!

  1. Vagabond shoes. Do not shuffle while delivering your talk. Try to keep your feet planted in one place, unless you are deliberately moving from one place to another (for example, to point at something on the screen). It can be distracting and annoying to see a speaker jiggle aimlessly about in front of the audience.
  2. Not knowing what to do with your hands. It's not easy to know where to put these handy appendages. By default, try to keep your hands mostly at your sides, unless you have something useful and non-distracting to hold (e.g. a pointer or some notes). It's OK to gesture to make points, but be warned that some listeners hate speakers who use fingers to point at their slides. Do not put your hands in your pockets. Do not put them behind your back.
  3. Not looking at your audience. Make eye contact with your audience. Don't focus on just one or two listeners; instead, try to look around the room periodically. Eye contact both exudes an impression of confidence and gives you a chance to gauge how the audience is responding to your talk. Look out for frowns or furrowed brows -- these are signs that some important point may have been missed. Don't spend all your time looking at your own slides or down at your notes.
  4. Not controlling your equipment. Set up your talk at least a few minutes before you have to give it. Make sure your laptop and the projector are set up correctly. Turn off the screen saver, and make sure you know how to back up one or more slides. If the talk is important, have a backup plan in case some piece of equipment fails. Is your talk on a floppy disk? Can it be downloaded from your homepage in an emergency? Do you need to print a version on transparencies just in case?
  5. Not watching your time. You are responsible for ending your talk on time. If the room doesn't have a clock, bring a watch and put it where you can glance at it periodically without distracting the audience. Consider in advance about how long each part of your talk should take, and recognize when you've dwelled on one part longer than intended. Plan in advance which material you might skip if you're pressed for time. Finally, if someone in the room is timing you (as is usually the case at conferences), make sure to watch for hand signals or signs from that person that you're getting close to the end of your time.
  6. Not practicing. Talks are more compelling if you speak smoothly and confidently, with few hesitations or mistakes. The only way to achieve smooth delivery is practice, preferably out loud (whether or not you have an audience). If you have access to a projector, practice with your slides displayed on the wall. Practice the parts where you get stuck several times until you can get through them smoothly. Coerce your advisor and your friends into listening to you at least once before the real talk. Bringing food to practice talks often helps to increase attendance!
  7. Being dull. For the duration of your talk, your research is the most important and interesting thing in the world. Your audience must believe this, and so should you. While designing, writing, practicing, and above all giving your talk, consider why you're enthusiastic about the work, and make sure you communicate that enthusiasm in your delivery.

Cindy Grimm adds:

  1. Write out words for the talk for each slide. You may not use those exact words, but that can keep your talk focused. If your text gets to be more than about a paragraph, you need to split up the slide.
  2. If you are always stumbling over some part of the talk, you need to rearrange/rewrite that part. Similarly, if you find yourself saying "oops, I forgot to mention...," then you need to add some slides or reorganize.
  3. I would more strongly stress giving the talk out loud to a room with the slides. The fifth talk is usually the best :). (Note from JB: even the second talk is often dramatically better than the first!)
  4. Remember that you are giving the talk to two audiences: one that is reasonably bright but doesn't know anything about your area, and one that knows your area very well. The latter audience is usually much smaller than the former. The first sentence or two for every slide should be at a fairly high level - what are you doing and why you are doing it. Don't start with the math or detailed algorithms. It's really helpful here to grab a friend in another area, go through the explanation, then have them tell you what they thought you said.

We hope that this advice helps you (and us!) give better talks.


This document was authored primarily by Aaron Stump, with input from Jeremy Buhler and Cindy Grimm.
Last update: 1/31/2003