I’ve given a number of talks, and over the years I’ve made the journey from completely unprepared to mostly knowing what I’m doing. After a lot of trial and error, I’ve settled into a routine that works for me. This has been the advice I’ve given to a number of folks who are looking to start speaking, or improve their existing technique.

I’ll break it down into three posts:

Writing

Everyone’s process differs for how they craft a talk. Some will think about it for months and then knock out the presentation in a couple of nights (or less). Some will set themselves a schedule. If you’re a new speaker, I’d recommend setting yourself time on a regular basis to work on the talk, while you work out what kind of process works for you.

Tools

How are you going to present your talk? Unless you’re going to draw everything on a whiteboard (not many people elect to do this), you’re going to wind up using a bunch of different tools. You could bikeshed on this for ages while writing your talk, and then wind up writing your talk on airport bar napkins on the way to giving it. Pick what tools you’ll use ahead of time, and agree to constrain yourself to those. You can revise that set before the next talk, but this will keep you focused for your current talk.

Red Shed, Flickr image CC-BY-2.0

Assuming you’ll be giving a technical talk, you may need:

  • Slides (Keynote, PowerPoint, Google Slides, LaTeX)
  • Editor (nope, not even going to touch this one)
  • Tech stack (yes, your stack is a decision you make)
  • Screencasting software (ScreenFlow, Quicktime)
  • Image editor (Photoshop, Illustrator, GIMP)

For your editor and shell, make sure you can zoom easily; if you’re demoing code, you’ll need to be able to increase font size so your audience can see. Additionally, get comfortable with your computer’s accessibility tools.

Outline & Write

For me, an outline has two purposes:

  • Validate my storytelling to myself
  • Guide my audience through the talk

Oftentimes, making my outline will show me that when spoken out loud, the talk doesn’t make nearly as much sense as it did inside my head. The outline helps catch these missteps before I get too far in development. Or said another way:

The outline is your talk’s design document.

I like to create my outline right in my slides. Agenda slides be damned, I just create slides for my section headers first, then fill those in with major subsections. They give your audience a clear idea what they’ll be hearing about (in case they didn’t read the abstract ahead of time). If you can’t read through your outline and understand the progression of how the sections flow into each other, consider reordering or restructuring.

Once you’ve gotten your outline in place, it’s time to fill in the content of your slides.

Coloring Book, Flickr image CC-BY-2.0

Depending on your talk, you might be creating charts, diagrams, and injecting code into your slides. Or, you might be leaning heavily on analogy and visual metaphor. Some people like to draw their slides on paper or post it notes, some folks dive right into Keynote. Whatever you do, try to minimize distraction during the writing process and focus on the content. You can make them pretty later.

Do:

  • Vary the format of your slides
  • Reinforce your main points in writing
  • Cite your sources, provide links to references
  • Include a question and/or thank you slide
  • Keep to short, succinct phrases

Don’t:

  • Make your slides a replacement for what you’re saying
  • Use language like “obviously” and “we all know that”
  • Use images without attribution (if Creative Commons)
  • Forget about the Code of Conduct

I recommend taking on one section at a time. Hopscotching around your presentation tends to lead to a fragmented narrative voice, and means a fair amount of work later on to tighten everything up.

Now, there might be phrases you want to make sure to nail, or jokes/anecdotes that you want to tell on a particular slide. The speaker notes section is a great place for these! Having them coupled with the appropriate slide can help you during rehearsals, especially during the first few times you go through your presentation. I like putting thoughts or clever ways of saying things in the speaker notes because a) my memory is terrible, and b) so I don’t get distracted from the core task of writing.

There’s a lot of hate for the idea of speaker notes out there, but I think that they can be very useful, particularly for technical talks where there are a lot of moving parts. When I write a new talk, I put a large amount of my narrative in there, and more detail for sections where I am less confident. That doesn’t mean I have to read from them, but it helps me develop what I am going to say to type it out. And if I’m going to type it out anyway, why not put it someplace useful?

After you have all the different parts of your presentation written, that’s when it’s time to make everything look good*.

* For some definition of good; this varies pretty wildly.

Demos

Demo for the Demo God, Tweet

A demo often is the most direct way of driving home the point of your talk. There’s nothing like seeing the tech you’re talking about in action! Demos can take many forms – a video, live coding, hands-on tour of an application, interactive with the audience, etc… A good demo is:

  • Simple and straightforward
  • Self contained
  • Analogous to other scenarios

The last point is really important. If the audience can’t see how what you’re showing relates to other problems, then all they’re getting from it is that you made A Thing™. Bonus points if you can relate it to a problem that they have!

If you’re going to attempt a live demo (and thus taunt the fickle demo gods), here’s my recipe:

  • Write down step-by-step instructions, including any work to do ahead of time
  • Set up a clean environment (separate accounts, profiles, etc…) for the demo
  • Get a video capture of a flawless rehearsal for backup

People get frazzled with live demos. Just knowing you have instructions nearby can help prevent mishaps. If you’re relying on any special account/machine configuration for your demo, you want to make sure that you have a clean setup for the demo.

Many a demo has gone awry because internet fails, because system upgrades happen, because new versions of an API gets released, or, or, or. If that happens, you can switch over to your video capture. I’ve had to do this a couple of times, and that’s okay. Everyone has had technology fail on them enough times to understand when it happens to someone else.

That said, don’t feel pressured to do a live demo! It’s okay to go with the video capture to begin with. It eliminates a lot of the preparation and allows you to focus on teaching.

Now that you’ve written your talk and created your demo, you’re ready to think about the presentation itself! Next up, I’ll talk about advice for preparing for and actually giving the talk to an audience.