DEV Community

Cover image for Debugging Slide Decks
Matt Eland
Matt Eland Subscriber

Posted on • Updated on • Originally published at killalldefects.com

Debugging Slide Decks

Ever have a presentation get off on the wrong foot or an intended point completely miss the mark?

I sure have.

Let's backtrack a few months and look at how I failed and 6 steps I now follow to keep getting better.


I was giving a monthly training presentation to my software development team and introducing a new testing library to them. Things had gone reasonably well up to that point on other topics, but people were getting mentally tired.

Speaking hasn't come naturally to me, but I started with a basic discussion of what the library was and why we might want to consider adopting it. They were on board with that so far.

Then I changed the slide and everything went off of the rails.

Instead of showing a basic example of the library, I showed them an example of how it would work using our existing code, My example had 8 lines of intimidating code chained together and introducing way too many new concepts at once.

It was a mess that they couldn't understand because I skipped over how it worked and went straight to where we'd use it and what that would look like with our code.


In retrospect it was something I should have expected, but I didn't. As I looked over the slide deck in preparation I saw no issues with my approach, but in the instant I was giving the presentation I knew I was teaching it the wrong way and I felt awful.

Not only had I embarrassed myself and made my team feel stupid and intimidated, I also failed to make the most of an opportunity to really help the team grow and grasp a new concept.

I apologized and sent out clarifying information afterwards, but in that moment I learned a lot more about teaching than my team did about mocking frameworks.


So what could I have done differently?

Probably a lot of things, but let me share what I've done since then:

1. Always practice aloud

This sounds simple, but I hadn't done it. It was a lot easier for me to present to my team than talk to an empty living room at home and so my preparation had been to run through the slides mentally thinking about what I'd talk about with each slide.

Practicing aloud forces you to focus on the transitions between slides and topics and, by extension, how it all flows together.

If I had given this presentation aloud at home in preparation, I would have discovered the massive leap I was asking my audience to make and could have prevented it entirely.

2. Practice on a TV with different picture / color modes

While on the subject of preparation and practice, practicing with a smaller TV set to washed out color modes forces you to notice lack of contrast in your slides, small code examples, etc. and make adjustments.

If you practice against bad equipment or bad color modes, you'll do a lot better in scenarios where a projector isn't as good as it should be or a screen is too small for audience members in the back.

3. Make sure people understand the what and how before they understand the why or where

This goes back to my example, but if you have something very technical, understanding the context is important before you go into the implementation details. If someone doesn't understand what something is, explaining how to invoke it won't help that.

Similarly, if you don't get the basics out of the way with simple examples, the larger ones will be too heavy for an audience - particularly if they're already mentally exhausted.

4. Keep in mind other ways of teaching

If you are giving a talk to a crowd and they're clearly not getting it, you may be able to change tactics to a different way of presenting it.

In my example, I would have been better off ditching my slides at that point and just going to the web page of the library in question and talking the team through the basic examples there.

In less technical discussions it might be helpful to have a few stories or metaphors in mind for if your preferred way falls flat, but read the audience and if it's something important that they're not grasping, find a way to help them find it.

5. Have additional material ready

In my example, I apologized to the team in the moment and made it right afterwards by providing more basic examples and reference materials via E-Mail after the fact.

I realized in doing this that this is something I should be doing no matter what. It's always helpful to have reference material or additional links for learning in more depth on your own time.

Not everyone is going to be giving everything their full attention and people who are mentally or physically tired aren't going to retain as much anyway. That's okay - you can help them get the most of things by providing simple resources like the slides to your presentation, links to GitHub repositories, or links to articles from helpful authors online.

6. When in doubt, include hidden slides

One of the other things that can derail presentations is random questions or concerns from people - particularly in the middle of a presentation. These are sometimes well-intentioned and sometimes not, but are often things you can at least partially anticipate if you spend a few minutes per slide thinking about what questions people might ask.

You don't have to have an answer for everything, but if there are a few obvious questions, I'll either have a pre-canned answer ready, have a slide for it later on in the deck, or I'll include a hidden slide for the subject that I can include if needed.

Often these are slides I cut for time or flow purposes, but they can save you from getting derailed and help the audience member focus on what you are saying vs what they are wondering about.

Typically I'll reply "Good question; I talk about that later on in this presentation" or "I have a hidden slide detailing more of that. Let me get through the presentation and if we have time at the end I'll pull that up and we can talk about it".

If you don't have an answer or expect a question you can handle it in a few different ways from "Good question. I don't have time to answer that in detail right now, but let's talk afterwards when I've had time to prepare" to "Good question. I don't know, but I'll find out and get back to you" or even "Thanks for asking, but that's not really included in the scope of this talk. We can meet later to talk about it if you'd like, I'm focusing on this right now".


Ultimately, the biggest thing that makes a difference for me is practicing and seeing how things would flow, picturing a few people from my audience and how they'd interpret each slide as I'm practicing.

Making these changes to my preparation has led to a better flow of slides, more confidence, an easier to understand and less jarring message, and better experiences for everyone around.

Not only are the slides more focused and thought out, the act of practicing aloud has helped me identify what really feels like it should resonate with the crowd as I say it and embrace that and tailor my message to emphasize it. As a result, my presentations are better even without slide changes than they would have been if I hadn't practiced at all.


What has worked for you that I haven't covered here?


Cover Photo by Helloquence on Unsplash

Top comments (0)