I recently had the great pleasure of giving a talk, Integrating React.js and Shiny, at rstudio::conf in Austin, Texas earlier this month.

Since I didn't bomb (and I have bombed) I thought I would take a moment to relay a set of guidelines related to presentation preparation and delivery that seem to be working for me.

I'm not a great presenter. I've seen great presenters, and I'm just not one of them. However, I really enjoy public speaking. Like writing, developing a presentation is a good way to refine an idea. Conferences are also a great way to network, especially among other speakers.

So, without further ado, I present to you four guidelines related to presenting that seem to be working for me. I hope you find them useful, and good luck on your next presentation!

Know Your Audience

Generally, conference talks — at least the kind I usually sign up for — are calls to action: they entreat the audience to learn/do/try some technical thing.

To convince a smart person to learn/do/try something is going to depend on at least that person's expectations, interests, and background.

Expectations

What the audience expects to be empowered to know afterward

When you're invited to speak at a conference, or looking for one to speak at, check out the previous year's talks: their titles, abstracts, length, subject areas. This information will inform your sense of what an attendee will expect from your talk if you give one. It should also inform your choice of topic, and crucially, whether you even want to speak.

Interests

Things the audience wants to know more about

The best way to connect with an audience is to identify and empathize with them somehow. For me, the best way to do this is to be the audience: I only speak at conferences that I'd also love to attend as well. As a member of that community, I share the same problems and aspirations, and any commentary I can offer will resonate with at least some of them.

Background

Knowledge about the topic the audience already has

Researching a previous years's conference talks is a good way to estimate the knowledge level of the prospective audience and to craft your topic, title, and abstract accordingly.

For large conferences, and especially multi-track conferences, you actually have some control here, through your talk's title and abstract: the audience will self-select. At large conferences about growing technologies beginners will outnumber experts, but if the conference is big enough there could be enough experts to fill your room.

Keep in mind that it's very difficult to develop a narrow technical (non-philosophical/non-experiental/non-keynote) talk that will satisfy both beginners and experts. In the worst case, beginners take nothing away, and experts are bored.

Be Excited

The few times I bombed, it was because I chose to speak on a topic I thought the audience would be interested in, but that I was personally no longer interested in.

Developing the presentation was a slog, and while delivering the presentation I felt like a fraud.

In retrospect, it would have been better for me and the audience if I had chosen to speak about what I was currently working on and excited about. Genuine enthusiasm really comes through in material and delivery in a way I can't fake.

You Are Telling a Story

At a high level, to give a talk is to tell a story and to unfold a plot. All of the devices in language and in writing to tell stories apply.

My talks generally follow something like the dramatic structure. For example, the talk's progression might look something like this:

1. Exposition: Here are some practices/packages/tools we are all familiar with
2. Rising action: Here are some problems typically associated with them
3. Climax: Here's a new perspective that addresses these problems
4. Falling action: Detailed comparison of old and new, demos
5. Dénouement: Here's where you can learn more and get involved

For my most recent talk, I tried something new: instead of an exposition, I began with a live demo on the suggestion of one of my brilliant co-workers, Mine Çetinkaya-Rundel.

I think it went over very well. In the future I want to read this book, The Seven Basic Plots, for more structure ideas. It looks really interesting. By starting with a compelling demo, I think my talk followed a structure like The Quest described in that Wikipedia article.

Rehearse

Only in the past few years have I committed myself to really rehearsing, and I think it's made a huge difference in the quality of both my material and delivery.

The toughest thing about rehearsing for me is that my material needs to be ready long before the talk day. As a generally deadline-oriented person (aka procrastinator) this is no small feat for me.

The past few talks I've given though, I've rehearsed at least twice and to at least one other person, and I feel those talks went far better than my prior talks.

Rehearsing to myself helps me develop material, because gaps in the story I'm telling are only evident when the story is told. It also helps me with timing, and most of the talks I've given had a strict time limit.

Recently I experimented giving a talk to a practice audience on YouTube. It worked OK, and might be a good way to rehearse if you're worried about standing in front of people.

Rehearsing to other people is even more valuable, especially if you can find friendly people to present to who can represent the audience you expect. The feedback from these rehearsals can dramatically improve your talk.