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
- 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.
- 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?
- 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.
- 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.
- 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
- 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.
- 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.
- 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.
- 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.
- 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!
- 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.
- 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.
- 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.
- 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?
- 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.
- 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!
- 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:
- 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.
- 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.
- 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!)
- 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