Contents:
(Also see my advice on giving a job talk.)
There are many good references regarding how to give an effective talk — that is, a technical presentation, whether at a conference, to your research group, or as an invited speaker at another university or research laboratory. This page cannot replace them, but it does briefly note a few problems that I very frequently see in talks.
Get feedback! One of the most effective ways to improve your work is to get advice from others.
The goal of a talk is similar to the goal of a technical paper. You have done some research, and you need to convince the audience that the research is worthwhile (is useful, solves a real problem), that it is hard (not already solved, and there are not other ways to achieve equally good results), and that you have solved it. If any of these three pieces is missing, your talk is much less likely to be a success. So be sure to provide motivation for your work, provide background about the problem, and supply sufficient technical details and experimental results.
Do not try to do too much in a talk. About one slide per minute is a good pace (possibly more if lots of your slides are animations that take only moments to present). If you try to fit the entire technical content of a paper into a talk, you will rush, with the result that the audience may come away understanding nothing. It's better to think of the talk as an advertisement for the paper that gives the key ideas, intuitions, and results, and that makes the audience eager to read your paper or to talk with you to learn more. That does not mean holding back important details — merely omitting less important ones. You may also find yourself omitting entire portions of the research that do not directly contribute to the main point you are trying to make in your talk.
Use descriptive slide titles. Do not use the same title on multiple slides (except perhaps when the slides constitute an animation). Choose a descriptive title that helps the audience to appreciate what the specific contribution of this slide is. If you can't figure that out, it suggests that you have not done a good job of understanding and organizing your own material.
The last slide should be a contributions or conclusions slide, reminding the audience of the take-home message of the talk. Do not end the talk with future work, or with a slides that says “the end” or “thank you” or merely gives your email address. And, leave your conclusion slide up after you finish the talk (while you are answering questions). One way to think about this rule is: What do you want to be the last thing that the audience sees (or that it sees while you field questions)?
Start your talk with motivation and examples — and have lots of motivation and examples throughout. For the very beginning of your talk, you need to convince the audience that this talk is worth paying attention to: it is solving an important and comprehensible problem. Never start your talk with an outline slide. (That's boring, and it's too early for the audience to understand the talk structure yet.) Always give the motivation or example first. It can be useful to show an outline slide at the start of each section, to help the audience stay on track (or help those who got distracted or lost to rejoin you), but often you don't need one for the introductory, motivational section of the talk.
I like to use outline slides throughout the talk: at the beginning of each major section of the talk, show the outline slide with the current section indicated via color and an arrow. This helps the audience to regain its bearings and to keep in mind your argument structure. But don't start off with an outline slide: usually the first instance of it comes after the introduction/motivation.
Make effective use of figures and color. Avoid a presentation that is just dozens of pages of text. Remember that about 5% of American males are color-blind, and augment color with other emphasis where possible.
Do not use non-single-color backgrounds, transition effects, and similar eye candy. At best, you will distract the audience from the technical material that you are presenting. At worst, you will alienate the audience by giving them the impression that you are more interested in graphical glitz than in content. Your slides can be attractive without being fancy. Make sure that each element on the slides contributes to your message; if it does not, then remove it.
When a subsequent slide adds material to a previous one (or in some other way just slightly changes the previous slide; this is sometimes called a “build”), all common elements must remain in exactly the same position. A good way to check this is to quickly transition back and forth between the two slides several times. If you see any jitter, then correct the slide layout to remove it. You may need to leave extra space on an early slide to accommodate text or figures to be inserted later; even though that space may look a little unnatural, it is better than the alternative. If there is any jitter, the audience will know that something is different, but will be uneasy about exactly what has changed (the human eye is good at detecting the change but only good at localizing changes when those changes are small). You want the audience to have confidence that most parts of the slide have not changed, and the only effective way to do that is not to change those parts whatsoever. You should also consider emphasizing (say, with color or highlighting) what has been added on each slide.
Use a sans-serif font for your slides. (Serifed fonts are best for reading on paper, but sans-serif fonts are easier to read on a screen.) PowerPoint's “Courier New” font is very light. If you use it, always make it bold, then use color or underlining for emphasis where necessary.
When giving a presentation, never point at your laptop screen, which the audience cannot see. Amazingly, I have seen many people do this! Using a laser pointer is fine, but the laser pointer tends to shake (especially if you are nervous) and can be distracting. I prefer to use my hand, because the talk is more dynamic (and the pointing is harder to miss) if I stride to the screen and use my whole arm. You must touch the screen physically (or come within an inch of it); pointing with your finger/hand from afar is confusing, as it is too hard for the audience to triangulate to what you are indicating (especially due to shadows and multiple points of view in the room).
Make eye contact with the audience. This draws them in and lets you know whether you are going too fast, too slow, or just right. Similarly, being animated is good, but do not pace. This is very distracting, and it gives an unprofessional impression.
If you get flustered, don't panic. One approach is to stop and regroup; taking a drink of water is a good way to cover this, so you should have water on hand even if you don't suffer from dry throat. Another approach is to just skip over that material; the audience is unlikely to know that you skipped something.
Think about your goal in giving the talk. When presenting to your own research group, be sure to leave lots of time for discussion and feedback at the end, and to present the material in a way that invites interaction after and perhaps during the talk. (When presenting to your own group, you can perhaps give a bit less introductory material, though it's hard to go wrong with intro material. It should go quickly for that audience, and it's always good to practice giving the motivation, context, background, and big ideas.)
For computer science conferences, the standard dress code is “business casual”: for men, a dress shirt with slacks. Some people dress more formally, some more casually.
Answering questions from the audience is very hard! Even after you become very proficient at giving a talk, it will probably take you quite a bit longer to become good at answering questions. So, don't feel bad if that part does not go perfectly, but do work on improving it.
Just as you practice your talk, practice answering questions — both the ones that you can predict, and also unpredictable ones. Giving practice talks to other people who are willing to ask such questions can be very helpful.
When an audience member asks a question, it is a good idea to repeat the question, asking the questioner whether you have understood it, before answering the question. This has three benefits.
Be willing to answer a question with “no” or “I don't know”. You will get into more trouble if you try to blather on or to make up an answer on the fly.
(Also see Tessa Lau's advice on giving a practice talk — which focuses on a practice talk for a PhD qualifying exam, but is relevant to talks in general.)
Always give a practice talk before you present in front of an audience. Even if you have read over your slides and think you know how the talk will go, when you speak out loud your ideas are likely to come out in a different or less clear way. (This is true about writing, too: even if you know what you want to say, it takes several revisions to figure out the best way to say it.) In fact, you should practice the talk to yourself — speaking out loud in front of a mirror, for example — before you give your first practice talk. In such a practice session, you must say every word you intend to in the actual talk, not skipping over the parts that are difficult.
It can be a good idea to keep your practice talk audience relatively small — certainly no more than 10 people. In a large group, many people won't bother to speak up, and if the pool of potential attendees is larger, it gives you the chance to give multiple practice talks, since the best feedback is given by someone who has not seen the talk (or even the material) before. Giving multiple practice talks is essential for high-profile talks such as conference talks and interview talks. However, the group shouldn't be too small, because otherwise you might be convinced to change the entire structure of your talk by one person who has a different view; getting a balance of opinions will help you avoid making too many mistakes in any one direction.
Consider videotaping yourself to see how you come across to others. This information can be a bit traumatic, but it is invaluable in helping you to improve.
When giving a practice talk, number your slides (say, in the corner), even if you don't intend to include slide numbers in your final presentation.
When giving a practice talk, it is very helpful to distribute hardcopy slides (remember to include slide numbers) so that others can easily annotate them and return them to you at the end of the talk. (Also, the audience will spend less time trying to describe what slide their comment applies to, and more time writing the comment and paying attention to you.) For non-practice talks, you generally shouldn't give out hardcopy slides, as they will tempt the audience to pay attention to the piece of paper instead of to you.
Go to other people's practice talks. This is good citizenship, and cultivating these obligations is a good way to ensure that you have an audience at your practice talk. Furthermore, attending others' talks can teach you a lot about good and bad talks — both from observing the speaker and thinking about how the talk can be better (or is already excellent), and from comparing the the feedback of audience members to your own opinions and observations. (This does not just apply to practice talks: you should continually perform such introspective self-assessment.)
Here are some other good resources for speakers who wish to give a good talk.
See Ian Parberry's speaker's guide.
The LaTeX Beamer documentation has some good advice.
Craig Kaplan transcribed some presentation tips from an unknown source, via Edward Tufte.
Back to Advice compiled by Michael Ernst.
Michael Ernst