Presentation and Live Demo Tips based on Mayer's Principles of Multimedia Learning

Have you noticed how some presentations flow super-smoothly and are easy to follow, while others leave you scratching your head in confusion? That's because our brains have very limited capacity to process incoming visual and audio information in real time, especially when we're passively watching someone talk without any prior shared context.

So how can you make a good presentation? Lots of people have written tips based on their personal experiences (see the appendix for examples), but it turns out that there's been decades of cognitive science research on this topic. The most well-known work here was by Richard Mayer and colleagues, which they distilled into Mayer's principles of multimedia learning. If you're curious, this is a good paper to check out: Nine Ways to Reduce Cognitive Load in Multimedia Learning.

These research papers are very jargony, so I want to translate their findings into practical plain-English tips for the four types of presentations that I often see:

• Slide: traditional slide-based presentations designed using tools like PowerPoint, Keynote, or Google Slides
• Sketch: sketching on a board (remember chalkboards?!?) or on a digital tablet like in Khan Academy videos
• Demo: demonstrating how a piece of software works by walking through using it live or recording a screencast video
• Livecode: live coding in front of the audience by writing and running code while narrating aloud

Before we begin, note that Mayer's principles translate into “micro-level” tips for how to present each individual slide or part of your demo, not macro-level tips about how to tell a good overall narrative (see Ranjit's guide in the appendix for narrative ideas). Also, it's probably impossible to abide by all of these principles in your presentation, so just use whatever feels right to you.

Here we go!

Minimize text

The ideal: images/animations + verbal narration

If you want to follow Mayer's principles strictly, then you should have only images/animations and no text anywhere in your presentation. That's right; no text at all! Instead, verbally narrate everything. (Yes, I know it's super-ironic that this article is all text and doesn't have any images or animations!) This means:

• Slide: one large image or animation per slide, and no text!
• Sketch: sketches are already fluid animations, so they're the ideal format for following this guideline; don't spend time sketching out any written text, which gets slow and messy.
• Demo: Live demos are already animations, so just verbally narrate while using the software.
• Livecode: Live coding is also like an animation, so again just narrate while writing and running your code. (Yes, code is text, but it's what you're presenting so that can't be avoided.)

Note how it's hardest to follow this guideline in slide presentations since it's so tempting to put too much text onto slides. It's not that slides are a bad format; it's just so easy to misuse them.

OK I know what you're thinking ... it's hard to get away with no text at all in a presentation. So ...

Some text right next to images is OK ...

If you can't resist adding text, add short captions right next to the images you're presenting on each slide (or hand-write text labels next to the images you're sketching). The less text, the better.

... but never text with animations

If you're going to play an animation, don't also display text explaining what that animation is doing. That's because it's impossible for your audience to both watch the animation and read the text ... and listen to you talk at the same time.

Note that this is mostly an issue for slide presentations, since if you're doing sketch, software demos, or live coding, the “animation” is the action you're currently demoing live, so you can't concurrently add extra text on-screen. But ... if you're recording a screencast video of your sketch, demo, or livecode session, then you might be tempted to overlay text captions on your video. Mayer and friends say that's a big No-No!

Text-only slides are OK, but don't add useless images

It's OK to have some slides that are solely text. But for those slides, don't try to spice them up with extra images like stock photos, clip art, icons, etc. that don't add to your message. Your audience will just glance at those images and get distracted.

Text-only slides should have as few words as you need to make your point. If you find that you somehow need to put a lot of text on a slide, split it into multiple slides. Also, use giant fonts. Here's a typical audience view at a conference presentation:

Unless you're sitting near the front, the screen is TINY. Can you see what's on-screen? But no fair ... this is a low-resolution photo! Well, it simulates my actual (lack of) view at the conference itself.

Visual Presentation Tips

Direct audience attention with precise visual cues

Direct the audience's attention to parts of the screen you want them to pay attention to while you're talking. Otherwise they won't know where to focus their eyes, and they'll waste valuable mental energy figuring out where to look while also trying to listen to you. This means:

• Slide: Add arrows to point to the relevant part of the slide that you're describing at each moment.
• Sketch: Draw an arrow to or circle the part of the sketch you're currently talking about.
• Demo: Move the mouse cursor and wiggle it over parts of your software that you're currently describing.
• Livecode: Wiggle the mouse cursor like in a software demo, and also select (highlight) portions of code in your editor for emphasis when you're describing them.

Finally, some people despise laser pointers, but when used carefully I think they can be good for directing audience attention.

Incrementally build up each small step ...

Visual cues like arrows or highlights are good for showing what to pay attention to at each moment in time. To show logical changes between moments, incrementally reveal what's new at each logical step instead of overwhelming the audience with a bunch of new material popping up all at once:

• Slide: Gradually build up parts of a diagram one piece at a time using slide animations (or multiple slides) rather than showing the entire diagram all at once.
• Sketch: You'll naturally build up your sketch incrementally as you draw, which is why this can be such an effective format.
• Demo: Show off each individual part of your software (e.g., select one option and show what happens when it's selected) rather than showing several features at once.
• Livecode: Write one tiny snippet of code at a time, run it to show its outputs, then write another tiny snippet; don't write a ton of code all at once before running it.

Each step should be smaller than what you think is necessary, to the point where you can't believe you need to break things down into such tiny pieces; it will all seem so obvious to you. However, your audience doesn't have nearly as much experience with the topic you're presenting (you suffer from the curse of knowledge!), so it's critical to break your presentation down into tiny steps.

... then pause after each step

After showing each step, pause for longer than you feel comfortable to let the new information sink into listeners' heads. This can feel really awkward, but if you race to the next step right away, they'll have to pay attention to something new before they've gotten a chance to absorb what they just saw. (If you're recording a video, this is easier to do since you can simply leave pauses between steps.)

Define jargon right before using it

If you need to use technical jargon in your slide or sketch presentation, define it clearly right before you use it. Also define as little jargon as necessary to show the next concept so the audience doesn't need to keep too much in their heads at once. If you find yourself needing to define several pieces of jargon before using them, instead (incrementally!) show several smaller examples with each piece of jargon used individually.

For instance, this is bad:

• define new jargon A
• define new jargon B
• define new jargon C
• define new jargon D
• show an example using A, B, C, and D (information overload!)

This is better:

• define new jargon A
• show a simple example using A
• define new jargon B
• show a slightly bigger example using A and B
• define new jargon C
• show a slightly bigger example using A, B, and C
• define new jargon D
• show the full example using A, B, C, and D

(This tip aligns well with the incremental build-up tip above.)

If you need to use jargon in a software demo or live coding session, ideally you should present its definition on-screen in a pre-made slide or write it out in your text editor.

Audio presentation tips

Speak in a conversational tone

Talk like how you would to a friend or colleague at work. Don't try to use a more formal “presentation voice.”

Eliminate unnecessary audio

Verbally describe only what's on-screen at each moment. Resist the temptation to make random asides or go off on tangents that aren't relevant to what's being shown on-screen. (I tend to do this a lot and need to restrain myself! See, I just did it again here.)

For recorded videos, this also means no background music. (Marketing demo videos are especially bad about this!)

Possible objection: “... but I want people to be able to read my slides afterward”

One common reason why people (including myself when I'm teaching classes!) jam tons of text onto slides is because they want others to be able to later read those slides standalone without re-watching the presentation video. In essence, they want their slides to serve as lecture notes or an article outline.

The bad news is that if you want slides to be effective visual aids for a great live presentation, they won't end up being readable afterward. And if you want to jam lots of text onto your slides so that they're highly readable, that will likely not make for a compelling live presentation. You can't have it both ways.

A compromise some people have struck here is to write out text in the hidden speaker notes section below each slide, and then render a PDF of each slide alongside those notes.

Appendix

Some other guides for giving slide presentations (Ranjit's in particular resonates with this article):

• (An Opinionated Talk) On Preparing Good Talks by Ranjit Jhala
• Giving an Academic Talk by Jonathan Shewchuk
• 10 tips for academic talks by Matt Might

And some tips from my own prior experiences:

• Tips for giving a live software demo
• PG's Super Practical Guide to Delivering Live Laptop Presentations
• PG's Super Practical Guide to Running User Studies (and Giving Live Demos)