Give a talk

This page presents advice on how to give a successful talk. You will likely give many different types of talks during your time at Brown: informal elevator talks, social discussions at parties, fast-forwards during CS orientation, sciviz lunch talks (which have their own explicit evaluation rubric), poster presentations at conferences, full talks at conferences, research comps proposals and defenses, thesis proposals and defenses. Each of these requires some unique understanding, but all of them share many common points. The advice below generally concerns hour-long talks, but can be adapted to any talk.

The central piece of advice, from which all the bits below may be derived, is this: the audience is always right. A talk may be about you and your work, but its real purpose is to convey ideas to your audience and to gather feedback from them. Your audience wants you to be clear, concise, efficient, and respectful. They want to feel like they understand what you're talking about, and they don't want you to waste their time or confuse them. The audience's interpretation of the talk is the reality of the talk. If you make a point but fail to convey it to the audience, you haven't really made your point. So always think about your audience when designing and refining your talk, and try to anticipate what they care about and what they'll be thinking while attending your talk.

Talk Structure and Content

Aim for an Audience

• Know who your audience is and tailor your talk to this audience. Different audiences expect different talk structures, expect emphasis on different points, make different assumptions, know different background, etc. When building or editing your talk, critically ask yourself: "does my audience understand this point?" "Does my audience care about this point?" Leave out details that your audience doesn't care about (as they might serve only to confuse, distract, or take time away in your talk). Make sure to include details that your audience does care about.
  • To find out who your audience will be, ask around with people who have given a similar talk at the same venue. On rare occasions, it can happen that you actually can't make a good guess about who your audience will be; for example, when you find out at the last minute that a much larger and more general audience will be attending your talk than you were told to expect. In this case, it's essential to gauge your audience's comprehension of your talk as you're giving it, and adjust on the fly. See the points below about "checkpoints" and asking questions.
  • Pro tip: your audience for a proposal or defense is the faculty. Each audience member therefore: has deep knowledge about a particular computer science subfield not necessarily related to yours, has a general knowledge of computer science, thinks about problems from a technical/algorithmic/data-oriented perspective, and is probably pretty geeky and detail-oriented. They will ask deep, probing, and potentially picky questions. Organize your talk to minimize confusion for this audience, and avoid irrelevant details that members of the audience might latch onto.
  • Bonus pro tip: think very explicitly about your goals for the talk. What do you want to convey to the audience? In most high-stakes talks, it's not just some fact that you worked out through your research. Other goals might include: "I want the audience to believe that I know what I'm doing." "I want my committee to let me graduate." Write these goals down and ask yourself whether the things you do and talk about in your talk serve them.
• Don't give the same talk to two different audiences. The point of a talk is to convey an idea to an audience. Each different audience has a different way of receiving ideas. This means that if you give a talk to two different audiences, it should not be the same talk, even if (to your mind) it's on the same subject.
• Understand the heterogeneity of your audience. No matter how uniform an audience might seem to be, it still contains different sub-groups. For example, for a thesis proposal presentation, your audience is composed of computer scientists, but it includes people from disciplines as diverse as natural language processing, computation theory, computational biology, and computer vision. For a presentation at an interdisciplinary conference (Vis or ISMRM, for example), your audience includes people from computer science as well as one or more application areas, and each of these communities has sub-communities (researchers vs. clinicians vs. engineers, for example).
• Be careful about terminology that means different things to different communities. Either be very explicit about the definitions of your terms, use unambiguous plain-language terms, or just drop them entirely and figure out a different way to present your point. An example list of problematic terms includes "greedy", "Monte Carlo", "solve", "optimal", "energy", "experiment", "model", "fit". If you're certain of the composition of your audience, some jargon of this sort may be acceptable, but remember that audiences are often more heterogeneous than you might think.

Make Them Care

• Tell them a story / put it in context. Your work will be most engaging when your audience understands as quickly as possible its basic context or purpose. You can achieve this by giving a simple example problem that motivates your work, an example of how someone would use your work, or an example of what your work looks like. If you can get people to care about your work in thirty seconds, put those thirty seconds at the beginning of your talk.
• Emphasize contributions, not design process. When working on a research agenda that includes multiple contributions, you may conceive of it as a sequence of experiments that you learn things from, where each experiment develops into or informs the development of the next. It's tempting to present your research in this way, to show it as a sequence of intellectual developments, but this is a mistake. Contributions are a concise and discrete way for outsiders to think about someone else's research; they provide a consistent framework in which your audience can understand the scope and impact of your work.
  • If you're really itching to talk about your design process, present each research item as a separate entity and discuss intellectual connections between them as a secondary point, later in the talk.
• Clearly formulate a "problem statement" for each contribution. The truth may be messier, but for the purposes of presenting research, it's important to summarize any given contribution in terms of the problem it aims to solve, its data inputs and outputs, and how you prove your contribution. This gives your audience the understanding necessary to truly engage with your work and to think critically about it.
• Show concrete examples. Your audience will understand what you're doing better if they have a clear picture in their minds of the format of your data and problem, inputs and outputs. Unless your audience is composed of people who have the same background as you, there will be some basic point that you have to explain before getting into the specifics of your work. If you work with medical images and you're talking to a non-medical audience, show an example image. If you work with visualizations and you're talking to a non-viz audience, show some canonical examples. When reviewing results, the same thing goes: show concrete examples at the level of detail appropriate for your audience, whether illustrations, screenshots, charts, tables, or something else.
• Don't overstate your case. Explicitly establish the assumptions built into your work and the scope of your hypotheses and conclusions. Think like a scientist or mathematician and be very conservative: unless you specify the scope of your statements, it may be assumed that they apply universally, which is almost always not the case.
• Don't understate your case. Don't state your hypotheses, conclusions, or contributions with such general language that they don't actually claim anything. Be specific about the work that you did (or will do) and point out (implicitly or explicitly) its novelty and significance.
• Clearly establish novelty and significance. If your audience doesn't know the related work that you're trying to improve on, show it to them and make it clear why your work is an improvement. A comparison table is a great way to do this; greater still is a comparison table with p-values.

Help Them Understand

• Number your slides. This way, audience members who want to ask questions about specific slides can note the slide number, to make the Q&A go more smoothly.
• Build in checkpoints. A "checkpoint" is a specific time in the talk where you want to make sure your audience is caught up. For example, if concept A may be difficult for your audience to understand but is essential for understanding concept B, put a checkpoint between the explanations of the two concepts. At this checkpoint, put an overview of concept A on the slide, and plan to ask your audience if they understand it.
• Clearly distinguish "figures" from "illustrations". Figures and illustrations are two different types of pictures. A figure is a picture that relates in a concrete and preferably quantifiable way to the work or point that you're presenting. An illustration is a generic picture that is evocative of the concept you're discussing. Trouble arises when a picture that you intend as an illustration gets misinterpreted by your audience as a figure. For example, this could happen with a bar chart. You may mean to present it as merely an example of a result that one might get, or a way that one might care to present a certain class of data, but if your audience identifies it as a figure instead, they will immediately start digging for details that will aid in its interpretation in terms of your work. This can almost fatally derail a talk. Try hard to reduce ambiguity by either removing irrelevant details from such illustrations (leave off axis labels on your bar chart, for example, and make it look as generic as possible) or by explicitly marking ambiguous illustrations for what they are.
• Clearly attribute your pictures. Whether a picture is a figure or an illustration, it's important to let your audience know if you did not produce it yourself. There are two reasons for this: for one, it's intellectually honest and the right thing to do. Furthermore, though, it helps your audience distinguish which pictures directly relate to your work, and which ones are more peripherally related.
• Use consistent symbols between slides. If a particular glyph, color, or figure means something specific in one slide, make sure it means the same thing in others. If you're talking about the same subject in two different slides, re-use symbols to clarify the connection between them.

Preparation for Your Talk

• Email a day in advance all audience members who are supposed to be there, just to remind them. This includes (for a thesis defense, for example) your advisor, your committee members, and the additional member of the faculty who you arranged to attend. Other people may have promised they would attend; email them separately. Make sure that all your essential audience members will arrive on time.
• Practice tricky sections. Memorize, if necessary, complicated terminology, slides with a lot of text, and complicated sequences of graphical transitions. Looking at your slides rather than your audience or stumbling over your words makes you look unprofessional.
• Practice in the same room where you will give your talk. Do it a couple times, and do it earlier in the day of your talk if possible.
• If you're using Skype, get a lapel mic. The mic on your laptop may not pick up your voice well enough from across the room. Talk with Media Technology Services about getting a mic.
• Arrive early to set up, an hour in advance if possible. Make sure your presentation is working right, that you've got all your materials on hand, that the projector works, etc.

Presentation Style and Audience Interaction

• Ask Skyped-in audience members to mute themselves. People listening on their laptops often make a lot of noise without realizing it, and this can be incredibly distracting amplified over the speakers during your talk. I've seen this fuck up several defenses. The person can un-mute themselves if they need to ask a question.
• Pace yourself. Pause at the end of each section or after each significant point to implicitly or explicitly wait for questions. Count off to yourself to make sure you don't rush through this pause; subjective "presenter time" and objective "audience time" go at different rates!
• Use a pointer (with discretion). Make sure you have a laser pointer or something equivalent (stick, telescoping pointer, finger that can reach the projection screen). When there are multiple things on a slide and you refer to them separately, indicate them both verbally and visually as you refer to them. Some people follow verbal cues better, while some are better with visual ones, so doing both covers your bases. Don't use your pointer when there's only one thing on a slide, or when you refer to multiple things as a single group; few things are more distracting than a laser pointer whizzing around needlessly. Note that a mouse pointer on the screen is not sufficient; it doesn't stand out enough against your slides and is hard to see. If using your finger, don't just point at the screen, actually tap the place you want to indicate.
• Check that your audience is following your talk. This is especially important when you have a mixed audience and a technically-difficult talk. You should have built some checkpoints into your talk; when you reach each one, ask the audience if they have any questions. If there's a specific point you need them to understand, ask them about it specifically. If they don't seem to understand, review the point and plan to go more quickly through some later section of the talk to make up the extra time.
• Finish on time. Most people find it disrespectful if a talk runs over its scheduled time limit; they have other stuff to do and don't want to choose between that and seeing your full talk (which includes Q&A afterward). It is entirely the presenter's responsibility to manage the talk in such a way that it will end on time (which is ten or fifteen minutes before the end of the meeting time, to allow for Q&A). If questions in the middle of your talk run long, that means that you have to adapt by speeding up or cutting out later sections of your talk. Talks usually start late and get interrupted a lot. It is your responsibility to plan for this. A thesis proposal, for example, is supposed to last an hour: plan for 35--40 minutes of uninterrupted talking time, knowing that you will start late, get interrupted, and have questions at the end.
• Avoid excessive marketing. Brooks: "Present to inform, not to impress; if you inform, you will impress." While it is important to avoid the question "who cares about this topic/problem?", it is also important to have your audience understand enough of the technical parts that they can draw on their collective wisdom to give advice.
• Show respect for audience comments. Note that this is different from having respect; you may have respect but still not convey it to your audience, which will alienate them from you. Here are some specific recommendations for how to convey respect:
  • Pause after every question so it's clear you're thinking.
  • Say the question back to the person who asked it (in your own words) to make sure you've got it right. Consider phrasing it as: "If I understand you properly, you want to know...".
  • If a question isn't clear, say you don't understand and ask them to re-ask.
  • Never cut people off, unless you can tell the rest of the audience agrees they're rambling or wasting time, and even then, be careful. Mention that you have time constraints and offer to talk about the question offline.
  • End every answer with "did that answer your question?" or something similar, even (especially?) if your answer is just, "that's a good point; I'll think about it".
  • Answer briefly. Don't spend a long time waffling if a simple "yes", "no", or "I don't know" will do. Defer to the commenter when in doubt.
  • Answer the question asked; don't spiral off into a discussion of something else unless it serves a point you're about to make.
  • Be efficient with your time; if your answer creates a back-and-forth discussion, try to defer it to the Q&A session so you can end your talk on time.
  • Respect ownership of ideas. When an audience member makes a suggestion during your talk, they may feel protective of their idea; it's a gift they're giving you, but it's important that you acknowledge that it comes from them. Some presenters try to engage with audience suggestions by connecting them to the work they've done, but this may be counterproductive. In the eyes of the person making the suggestion, this may seem like you're trying to take their idea away from them and claim it as your own, or that you don't understand the significance of what they're saying. Your first priority should be to acknowledge the wisdom of your audience. The easiest and quickest way to do this is to say something like, "that's a point I hadn't considered; thanks a lot for bringing it up. Can we talk afterward about how to incorporate it into my work?"
  • Generally speaking, keep in mind: the audience is always right.

Post-talk

After giving a talk, add your presentation to /pro/graphics/talks/[name].