Search results

The ideal number of slides for an hour-long presentation, and other thoughts on preparing slides

by Tom Johnson on Oct 15, 2018
categories: technical-writing

When giving an hour long presentation, about 15 slides is ideal. Although having fewer slides might make you panic about possibly forgetting what you want to say, in reality fewer slides gives you more flexibility to narrate your idea journey in a dynamic way. If you have too many slides, it locks you into a fixed, rigid structure that can actually make presenting harder. Additionally, a good essay is often the foundation for a good presentation because many of the rhetorical elements of an essay (the introduction, thesis, evidence, argument, etc.) are reflected in presentations as well.

Comparing two recent presentations

These past two weeks, I gave two presentations — a keynote at an internal writers conference at SAP, and a keynote at an internal writers conference at Amazon. (Sorry that I can’t post the recordings.) Both presentations filled an hour time slot. Because I’ve been in presentation mode this past month, especially preparing slides, I’d like to share some thoughts I have about how to create slides for presentations.

Hands-down, the best advice for creating slides is Guy Kawasaki’s 10-20-30 rule of PowerPoint, which says you should have just 10 slides, your presentation should last no more than 20 minutes, and your font should be no less than 30 points.

The right number of slides

I have aspired to follow Kawasaki’s slide rule for a number of years, but one fear always gets in the way: if I have just 10 slides, what if I run out of things to say after 20 minutes? I mean, usually I have to fill an hour presentation slot, right? In order to guard against running out of time, I have a tendency to add more and more slides, helping me remember points I want to make and ensuring I don’t end early.

With my first keynote presentation, I unfortunately had 50 slides (and got through about 40 of them during the presentation). (Granted, many were “sub-slides,” but they were still slides.) For my second presentation, I had only 14 slides (and got through them all). I felt the second presentation went better than the first.

Here’s the problem with having too many slides: the slides lock you into a fixed, rigid presentation order. The more slides you have, the more locked in you are to a fixed set of topics in a predefined order — which may or may not be the right order you want while presenting. With 50+ slides, you won’t have the freedom and flexibility to flow in a more natural way. The more slides you have, the more fixed the order becomes. Instead of a crutch, these slides become a cast that restricts your movement.

The absolute best presentation I’ve ever attended was by David Crystal at UA Europe, and he had no slides at all. He simply had a stool where he occasionally sat, and he spoke for about an hour and a half. It was the most mesmerizing presentation I’ve ever attended, and much of it focused on grammar (and stories about the origins of language). Crystal is the author of some 100+ books on language, and after the presentation, it was clear to me that he was a complete language genius.

I once gave a 20-minute presentation with no slides at all (at a WordPress conference), and I felt a bit naked. It wasn’t a great presentation, but it didn’t tank either. At some point, I’d like to develop the ability to present with just a few slides. I think such a presentation would resemble that of a stand-up comedian or other performer (like the Moth). I don’t have stage performer skills, so I doubt the slide-less presentation will ever be something I pull off. Still, I think as a general rule, the fewer slides one has, the more knowledge and experience the presenter has. Lots of slides is a red flag that the presenter isn’t an expert.

Until I can go slide-less, I have compromised at what I feel is the ideal number of slides for an hour-long presentation: about 15 slides (including the title and conclusion slides). Kawasaki says to limit the number of slides to 10 because no one can retain any more than 10 ideas in an hour, and though I don’t know what data supports this, I generally agree. I bumped my estimate up from 10 to 15 because Kawasaki’s ideal time of 20 minutes seems too short for the hour-long time slot.

Limiting the number of slides to 15 provides the perfect balance between flexibility and structure. You can pursue your ideas in a more freeform, natural way without being locked into a fixed, rigid order that might not fit the idea journey of your presentation.

You might object and say that if you practice your presentation enough, the slides can exactly match the idea journey you want to tell. Hence, you wouldn’t be locked into a structure you don’t want — instead, the slides would help you follow that desired structure.

Well, maybe. But I’ve given about 90 presentations, and it never seems to work out that way for me. Consider the analogy of a conversation. You want to have talking points that allow you to move about in a more freeform way, not necessarily a rigid order in which each topic must be spoken. If you imagine yourself having a conversation with the audience (rather than presenting a presentation), the talking points idea has more merit.

Font size and bulleted lists

Another Kawasaki principle is to limit the font to no less than 30 points. This is also key. When I see slides with extensive bulleted lists, I cringe. While these bulleted lists might prompt the presenter with details to say, what ends up happening is the presenter more or less reads the slides and presents the presentation rather than telling a story.

Whenever you present a slide with text, the first thing the audience does is tune you out and start reading the text. As an audience member, it’s impossible not to — the screen is huge and directly in front of you.

If you reveal the bulleted list point by point, it has the same effect as flashing multiple, separate slides on the screen: It locks the presenter into a fixed order that potentially interrupts the natural flow of the story.

Ideally, I think good slides should be idea diagrams or visual sketch notes that demonstrate your ideas. Some presenters just put photos from Flickr on their slides to generally depict an idea, but I like more purposeful concept diagrams that might have multiple ideas going on. For example, like this:

Or like this:

Granted, some font on these slides is less than 30 points, but you don’t see extensive bulleted lists here.

For my second presentation slides, I tried to include about 3 stories per slide depicting concept diagrams like this. My thought was that I could glance at the pictures, and each picture would trigger 3 points to cover for the topic. I could cover the 3 stories/points in whatever order I wanted, so I wasn’t locked into a fixed outline. It more or less worked.

I also had slide notes in the presenter view that I could fall back on, but these presenter notes are challenging to read while speaking, and I think most presenters end up ignoring them. Pictures that trigger thought without interfering with one’s language-speaking functions work much better (for me anyway).

I use The Noun Project and Illustrator to create my concept diagrams, as it allows me to more easily manipulate different objects into the slides I want. The images aren’t spectacular, and they’re mostly black and white, but they aren’t embarrassing either, and I have fun making them. I end up exporting these artboards into my presentation. Each artboard is basically a slide in my presentation.

I use RevealJS for my presentations (and have been for the past several years). RevealJS is an HTML/CSS/JS framework that lets you code your slides with simple HTML syntax. For my second presentation, I put the SVGs as slide backgrounds, leaving ample room on the sides to allow for visibility even when the slide show is not in full screen. This worked quite well.

I also put each RevealJS slide presentation into its own GitHub repo. This makes it easy to update the slides. Kawasaki doesn’t say anything about RevealJS, PowerPoint, Google Slides, or Keynote. It really doesn’t matter which tool you use. (I just added some tool-related details here in case you were curious.)

Avoiding laundry lists

I’ve given many presentations that turn out to be laundry lists of points — a format I regret. This was the problem with my first keynote presentation. After highlighting a trend, I started listing a number of points that could provide solutions to the challenge. These “laundry list” topics tend to be on a lower-level than topics that provide a fuller, richer argument throughout.

Here’s an example of what I mean by a laundry list. In my first presentation, my argument overview was this:

  • Technology is getting simpler on the front-end for end-users
  • But the code underneath is becoming increasingly specialized/complex
  • Tech writers are generalists, not specialists
  • To provide value in specialist contexts, tech writers must exploit the gaps
  • These gaps are (1) doc tools/processes, (2) understanding user feedback/experiences, and (3) information usability

Then within the “(3) information usability” section, I covered these points:

  • Give users a map
  • Make information discoverable as needed
  • Ensure harmony across all docs
  • Reduce and distill to its essence
  • Confirm to genre expectations
  • Reduce language complexity
  • Iterative design of docs

Can you see how the presentation just devolved into a laundry list of points rather than focusing on a more focused idea journey? The laundry list comes into focus with the “(1)”, “(2)”, “(3)” points in the last bullet, followed by the 7 bullets later. When I was a composition teacher, I docked student essays for presenting similar laundry lists of ideas rather than going in depth with one point.

For my second presentation, I decided to chop out this laundry list of ideas and instead focus more singularly on my trends argument. So my argument overview was as follows:

  • Technology is getting more specialized/complex.
  • This complexity drives up the value of technical knowledge, making it more prized than writing skills.
  • To handle the complexity, technical writers must play increasingly collaborative roles with engineers to create documentation

And that’s it. No laundry list at all. I instead spent much more time developing, supporting, and exploring each of these parts of my argument.

Argument overview slide

Speaking of arguments, I also recommend putting up an “Argument Overview” slide right after your intro hook slide (which usually comes after your title slide). In other words, after you introduce the relevance of your topic, present the audience with your overall argument, so they know where you’re going and what you’re arguing for.

Many presentations will omit this argument overview. When they do, I find myself wondering what the presenter’s overall point is, if they even have one, or if they just have a collage of lots of little ideas. People can often take 10-15 minutes working their way up to some point, which they articulate in fuzzy ways.

I think a good presentation mirrors the elements of an essay:

  • title
  • relevance hook
  • argument/thesis

Many other essay elements might be reflected as well.


Kawasaki says to limit your presentation to 20 minutes. His main scenario isn’t presenters at a conference but rather presentations from startups to venture capitalists (VCs), and he doesn’t really give much reason here for the 20-minute length except to sarcastically say that if you have a Windows machine, it will take 40 minutes to troubleshoot the display. My guess is that VCs are executive types who have a lot of questions and don’t want to be lectured at extensively.

For too many presentations I’ve given, I’ve filled the entire time slot, without leaving any time for questions. This has been a mistake, in part due to having too many slides in the first place. For my second keynote, I spoke for only about 40 minutes and then let Q&A dominate the remaining 20 minutes. Although as an audience member I sometimes dislike listening to other audience members ask questions, I do like to ask my own questions.

Further, very few people can sit patiently listening to a lecture for an hour without engaging with more interactive dialogue. My brain isn’t wired to listen to lectures this long, and neither are many other people’s. You have to be pretty interesting to retain my attention for a full hour in an engaging way.

Probably the biggest reason, though, is that the purpose of a conference is not to present lectures — it’s to confer. You come together to confer with other people, and so you need this space to allow time to discuss your ideas.

What if no one has any questions, and you’re done 20 minutes early? Won’t that feel like you didn’t fill the time, that you short-changed what you promised?

If no one asks questions, it might mean you didn’t make a real argument in your presentation, but instead focused on something everyone already agrees on.

Coming back to the essay comparison, a good presentation focuses on an argument. And an argument must be something that people can take different sides on. If everyone already agrees on the position you’re taking, why bother making it in the first place? Are you already telling people something they already know?

I realize that many presentations at conferences are more information-based rather than argument-based, and people come to “learn” rather than to “debate,” but I’d counter that almost every topic has areas of controversy or uncertainty, and I like to see someone taking a position and defending it with evidence. This shows my bias towards the essay format, as I think good essays reflect this focus as well.

At any rate, if you’ve focused on some argument that people can disagree about, then ending 20 minutes early for Q&A should be ideal, as you will have set the stage for a lively discussion — which is one draw to these gatherings in the first place. You’re setting up the discussion and then allowing for the audience to engage in critical thinking.

Additionally, note that as a presenter, you can also be the one to ask questions. A good teacher doesn’t just lecture to students for 20 minutes and then ask them what questions they have. The teacher asks challenging questions to students and invites them to engage. Why can’t presenters at conferences do the same?

A good essay makes for a good presentation

A good essay and a good presentation share many similarities. For many presentations I give, I’ll often write out the content as a blog post or essay before hand. For example, for my second keynote presentation, my Tech comm trends - take two post was the essay form of the post. The essay was about 8,000 words, which is about right for an hour-long presentation. For my first keynote, the essay was an earlier version of the same trends topic.

If the essay doesn’t have a good shape and focus (no idea journey, no story arc, no argument, no evidence, no analysis of opposing views, no interesting questions, etc.), then the presentation will probably lack life as well.

The absolute best advice for any presentation is to structure the idea journey as a story. I don’t mean to pepper in anecdotes everywhere (though that is actually great advice). I mean presentations should follow the general story arc. You have some sort of goal, and you encounter challenges to that goal. The bulk of your work is in getting through these challenges, until you finally come to some realization or conclusion. This flow aligns perfectly with the essay format.


Although I’m not a professional presenter and I lack more training and polish, in the presentations I’ve given over the years, fewer slides work better than more slides. Overall, if I can shape the essay right in the first place, it usually eliminates most of the problems with presentations. That’s why I spend about 90% of the time writing the essay first, and then in the last couple of weeks create the slides.

About Tom Johnson

Tom Johnson

I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.

If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.