Give a talk: Difference between revisions

From VrlWiki
Jump to navigation Jump to search
Jadrian Miles (talk | contribs)
No edit summary
Jadrian Miles (talk | contribs)
Summary advice from thesis proposal feedback
Line 1: Line 1:
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, [[SciVis Meetings|sciviz lunch talks]] (which have their own explicit [[SciVis Meetings#Rubric for SciVis Talks|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.
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, [[SciVis Meetings|sciviz lunch talks]] (which have their own explicit [[SciVis Meetings#Rubric for SciVis Talks|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 central piece of advice, from which all the bits below may be derived, is this: '''the audience is always right'''.  This talk may be about you and your work, but the people evaluating its quality are the audience.  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'll be thinking while attending your 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'll be thinking while attending your talk.
 


=== Talk Structure and Content ===
=== Talk Structure and Content ===


* '''Know what 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.  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. When building or editing your talk, critically ask yourself: "does my audience ''understand'' this point?" "Does my audience ''care'' about this point?"
* '''Know what 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.
* '''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 audiences are often more heterogeneous than you might think.  For example, for a thesis proposal presentation, your audience includes people from disciplines as diverse as natural language processing, computation theory, optimization theory, and computer visionFor 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, for example).
* '''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.
* '''Use consistent symbols''' between slidesIf a particular glyph, color, or figure means something specific in one slide, make sure it means the same thing in othersIf you're talking about the same subject in two different slides, re-use symbols to clarify the connection between them.
* '''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 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.
* '''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.
* '''Tell us a story'''.  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.
* '''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.
* '''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.
* '''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.  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.
* '''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 intuitive to explain your research in this way, to show it as a sequence of intellectual developments, but presenting it in this way to an audience is a mistake.  If you show in a figure how one experiment leads to another intellectually, your audience will likely interpret this to mean that there is a data flow from the first process to the second, which may not be the case.  Instead, present each research item as a separate entity and discuss intellectual connections between them as a secondary point.
=== 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 member of thel [http://www.cs.brown.edu/people/faculty/committees/ Graduate Exams Committee] 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.
* '''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 ===
=== Presentation Style and Audience Interaction ===
 
* '''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.
* '''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!
* '''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!
* '''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.
* '''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.
* '''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:
* '''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.
** '''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.
** '''Say the question back''' to the person who asked it (in your own words) to make sure you've got it right.
** If a question isn't clear, ''say you don't understand'' and ask them to re-ask.
** 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.
** '''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.
** 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".
** 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 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.
** '''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.
** '''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 the ownership that the person asking a question or making a comment has over their ideas.  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.
** '''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'''.
** Generally speaking, keep in mind: ''the audience is always right''.
** Generally speaking, keep in mind: '''the audience is always right'''.
* ''Make sure all key audience members are there''.  For a proposal or defense, this includes your committee members and a member of the departmental [http://www.cs.brown.edu/people/faculty/committees/ Graduate Exams Committee].  Make sure that your committee and exam committee member are all there on time.  Jadrian didn't have an exam committee member at all, and was fortunate that one came serendipitously.  Ben Raphael was late, but knew and had had some issues with traffic that would have been difficult to avoid.
* '''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.
* Avoid excessive sales/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 committee understand enough of the technical parts that they can draw on their collective wisdom to give advice.
* Answer questions with care.  Rephrase the question, to make sure you are understanding the question that is being asked.  During the presentation, try to answer briefly.  Only go into a longer answer if the point brings up something you were going to present or something that you are willing to drop part of your planned presentation to include.  With the committee alone, longer responses are good.
 
 
 
I  think I explained that I aimed my talk at the wrong audience: I
designed it for a general audience, not for CS people (and in
particular, not for CS faculty who are very critically evaluating my
work, plans for future work, and ability to work seriously).  For the
most part, your talk was aimed exactly right, but at some points I
think it was also aimed at a *different* wrong audience than mine was:
you're talking as though you were at ISMRM, rather than the CIT.
 
Nobody in the CIT cares about double PGSE.  Nobody in the CIT knows
what diffusion MRI or macaques are.  Nobody in the CIT knows the
clinical or research neuroscience context for the kinds of tools
you're building, nor the problems you're trying to solve with them.
In some cases (double PGSE), this means you don't have to bother
talking about certain things.  In others (diffusion MRI, macaques,
research context), this means you have to explain yourself *just
enough* to motivate the work you're doing, explain the data you're
working with, define central terms, and make people feel like they
understand enough to ask intelligent questions about *your work*,
which is the true focus of the event.  This may mean simplifying or
leaving things out that someone in an ISMRM audience would feel were
necessary to discuss, or mentioning things that an ISMRM-er would feel
were unnecessary.  But you're not at ISMRM; you're in the CIT.
 
Second thing:
 
In working with David, planning our research, and discussing our
research with each other, we conceive of it as a sequence of
experiments that we learn things from, where each experiment develops
into or informs the development of the next.  It's intuitive for us to
explain our research in this way, to show it as a sequence of
intellectual developments.  Based on the feedback to my proposal talk,
however, I believe that presenting it to the department this way is a
mistake.
 
Do you remember from my talk the "big picture" diagram that showed the
multiple phases of my research, connected by arrows?  Three projects
involving macrostructure, two involving microstructure, and one that
combined them.  To me, the arrows indicate intellectual progress, the
development of a set of research ideas.  To the audience, I'm pretty
sure they indicated a data flow, which confused a lot of people, and
understandably so, because they're *not* data flows.
 
You use arrows in a similar way in a couple places, and I think they
caused similar confusion in your practice talk tonight.
 
The lesson here, I think, is that you shouldn't worry a lot about
explaining the intellectual framework of your research, how each
experiment or contribution leads into the next.  Instead, you should
just present each research item as a separate entity (say, a numbered
or bulleted list of research projects), and discuss the connections
between them as a secondary point.  Talk about each one as a
more-or-less standalone research activity, as it must be in your
publications.  Introduce each one by explaining the problem it aims to
solve, its inputs, its outputs, and how you'll prove your
contribution.  Then explain that introductory outline in more detail
if necessary.
 
After you've gotten all of that out of the way, you can explain to the
audience how your research forms a cohesive and flowing whole, but at
first they want "just the facts".  Anything else will confuse them at
best, and possibly alienate them or make them think you're trying to
be deceptive at worst.
 
Okay, so that's that.  Here are my notes, with additional comments in brackets.
 
----
 
INTRO
 
Number your slides
 
Scale bars on micrographs
 
Awesome intro.  Question slide ["how do we do this non-invasively?"]
is a great idea.
 
[Discussion afterward indicated that it would help for you to include
some more motivation early in your talk.  Here's why we study the
brain, here's how a researcher could use my tools.  Show how your
tools match step-by-step the same investigative procedure that you
describe for traditional neuroanatomy and dissection on the slides
with the black backgrounds.]
 
Practice your thesis statement so you can say it smoothly.
 
Overview based on thesis statement is good too.
 
[Also important to explain briefly what diffusion MRI data describe
and what they look like.]
 
---
 
QUALITATIVE TOOLS
 
[Important to explain that tractography curves are a standard
representation of the brain derived from diffusion MRI data, and that
your quantitative tools take these curves as inputs.  Define inputs
(tractography curves) and outputs (manually selected sets of curves
that correspond to an experimenter's tract of interest) for your
contributions.]
 
Compare your TOI methods to the usual methods.  Why is your technique
easier?  [Your audience doesn't know the state of the art or what
people usually use.  Introducing that quickly will make them
understand why there's a need to improve these tools and why your
technique is an improvement, even without you demonstrating it based
on your experiments.]
 
Do you have anything stronger than expert feedback?  Show charts.
"Expert feedback" seems weak and anecdotal.  [Some of your results are
anecdotal; some are quantitative.  Presented the way you currently
have them, it looks like *all* your results are anecdotal.  People
will disregard the non-quantitative stuff for the most part, and
that's okay.  Be sure they get to see the stuff they won't disregard.]
 
---
 
QUANTITATIVE METHODS
 
[Clearly state that now you're working with diffusion MRI data in
individual voxels, with the goal of recovering microstructure
measures.  Remember, what computer scientists understand is input ->
(your transformation) -> output.  Use pictures to show what an
individual voxel looks like.  This should make it clear that you're
not talking about tractography curves anymore.]
 
[This could be a good place to put your ONE mention of double-PGSE,
which you can just describe as an "alternate technique for diffusion
MRI scanning that provides some additional information in its output"
or something like that.  After that, no need to mention double-PGSE
again, though in your related-work comparison table you can leave
references to the acquisition used in each process as long as they're
de-emphasized.]
 
Single of "radii" is "radius"
 
Assumptions slide is great.  Contrast to related models?
 
Explain q-value briefly [or leave out references to it if possible.
You could instead just mention that some techniques use single-PGSE,
which requires clinically infeasible acquisition times.]
 
Connection between citations and what you're talking about should be
clear.  If it's not obvious (that is, obvious to your audience without
you explaining, referencing, or otherwise talking about it, which is
*extremely* rare) or explicit (that is, explicitly described by its
presentation on the slide or your oral explanation of it), leave it
off the slide.  [Same goes for figures.]
 
Related work slide is great.  Move it [or copy it, per Steve's
suggestion] to the beginning of this section.
 
Say the names of D and f.  Those who care will want to know; everyone
else will ignore.
 
[As Justin and Carleton mentioned, you should make sure your audience
knows enough to understand the column headings of your related work
table.  Maybe structure your background around that?]
 
The traditional understanding of a model is that it is *fit* to data.
[That is, right now you use some unusual verbs connecting your data to
your model.  We had a really long discussion about this.  Your model
exists independent of data; it is a list of variables.  You fit the
model to the data by some fitting/learning process in order to
generate a model instance, which is a list of *values* for the
variables.  Just like class vs. object.  Make this distinction
absolutely clear in your talk.  First discuss the model and how you
developed it.  Then discuss the fitting.  Each is important, each is a
contribution, and each is an independent concept.]
 
[Carleton brought up concerns about the term "Monte Carlo".  Be
careful; it means different and very specific things to different
people.  It's not central to your discussion, and in fact it sounds
like you didn't even design the software to do the simulation.  Just
call it a physics simulation and explain *precisely* what the output
from it looks like.  If someone else wrote the software, tell us the
name of the software.  Leave the potentially dangerous term "Monte
Carlo" out of it.]
 
Does your physics simulation take finite gradients into account?
[This was a question that I wanted to ask as an audience member, not
one you should address ahead of time.  It's unlikely that anyone will
ask.  In this way it's similar to the question about why the hindered
component of your model didn't incorporate angular dependence.]
 
What's "XOY plane" mean?
 
Ditch references to PGSE, and especially "experiments".  The process
of you designing the model doesn't require you to collect any data.
["Experiment" is another one of these terms that means different
things to different people.  Some clinicians call every scanner
acquisition an "experiment".  Nobody else uses the term this way.  For
everyone in your audience on Wednesday, a scan is a data acquisition,
and that has to do with *fitting*, not the design of your model.]
 
"Simulation axon radius" should be "Simulation mean axon radius" on
the X-axis of your various results bar-charts for the model that
considers a gamma distribution of radii.  [And, as we discussed at
some length, just throwing all your tables at the audience serves only
to confuse.  Pick a couple good ones and explain what they tell us
about your work *compared to your competition*.  You want to reassure
us that you do as good a job or better than all the related work you
described in that nice table earlier on.  If people want all the
grisly details, they'll look up your papers or ask you.]
 
Where are the error bars?
 
---
 
QUANTITATIVE METHOD VALIDATION (PROPOSED WORK)
 
The vertical arrows are confusing.  Number the three stages of your
validation instead.  [See my second point at the top of the email.]
 
"Solid" recordings?
 
Somehow clearly and explicitly specify, for each phase of validation,
the following characteristics of your input data and the source of
your "ground truth" for validation: in-vivo / ex-vivo; MRI /
histology; human / monkey; values recorded in the literature / your
work.
 
"Expensive" not "expansive"
 
Use a different term than "same brain".  Step 2 is in the same brain
too, so saying "same brain" for step 3 is confusing because it implies
that step 2 is not.
 
What does "bonus" validation mean?  Are you gonna do it or not?  Be
explicit and spin positively.  [That is, cast it as "I will do (or
would like to do) one of these things, the selection of which will
depend on logistical issues.  If the progress of my main research
requires that I adjust my plans, I may have to skip this component."
Right now you're saying, "I might do one of these, maybe, if it all
works out", which, as Aggeliki pointed out, most of your audience will
interpret to mean that you're just not gonna do it.]
 
---
 
Total talk time, with interruptions: 43 minutes.
 
[On the day before your talk, email everyone who's supposed to be
there to remind them.  On the day of your talk, show up at least an
hour early to test your hardware, adjust the thermostat, adjust the
projector, plug in your laptop, etc.  Practice once or twice in the
same room where you'll be giving the presentation.]


Good luck!  I'm sure people will like your talk.  See you Wednesday morning. =)


[[Category:HOWTO]][[Category:Dissemination]]
[[Category:HOWTO]][[Category:Dissemination]]

Revision as of 15:33, 15 October 2010

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 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'll be thinking while attending your talk.


Talk Structure and Content

  • Know what 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.
  • 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.
  • 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.
  • 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.
  • Tell us a story. 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.
  • 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.
  • 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.
  • 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. 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.
  • 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 intuitive to explain your research in this way, to show it as a sequence of intellectual developments, but presenting it in this way to an audience is a mistake. If you show in a figure how one experiment leads to another intellectually, your audience will likely interpret this to mean that there is a data flow from the first process to the second, which may not be the case. Instead, present each research item as a separate entity and discuss intellectual connections between them as a secondary point.


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 member of thel Graduate Exams Committee 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.
  • 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

  • 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.
  • 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!
  • 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.
  • 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.
    • 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.
    • 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.
    • Generally speaking, keep in mind: the audience is always right.
  • 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.