A Few Things I’ve Learned About Making Good Conference Decks
A few practical things I’ve learned from years of making conference decks - from simplifying slides and using visuals well to designing for the actual room, not just your laptop.
I’ve been speaking at conferences and meetups for quite a few years now, and I tend to spend a good amount of time on my presentation decks. One thing I’ve always cared about while speaking is breaking things down and making them easier to understand, and the deck plays a pretty big role in that.
Every now and then, people also ask me for tips on their decks. Most of the time I end up sharing these things 1:1, reviewing someone’s slides or talking through what I would change. So I thought it’s probably better to document some of the things I’ve learnt over the years here.
I’ll use examples from one of my recent conference talks, “What I Learned Building Payments (So You Don’t Have To)”, which I presented at React Nexus. If you want to look through the deck while reading this, you can keep it open alongside the post: Deck Link
That deck went through a lot of iterations, and it gave me plenty of examples of what worked, what didn’t, and what I eventually removed.
These aren’t really rules. Just a few things that have consistently worked for me.
1. One slide, one main idea
This is probably the thing I follow the most. Before making a slide, I try to ask myself: what is the one thing I want people to take away from this slide?
With technical talks, it’s very easy to keep adding context because everything feels important. A diagram gets another box, then another arrow, then a note explaining the arrow, and eventually you have a slide that needs a minute just to understand.
I ran into this a lot while building the React Nexus deck. Payments have a lot of moving parts - authorization, fraud checks, authentication, redirects, retries, failures, browser limitations and all the systems involved. Instead of trying to fit the entire payment architecture onto one screen, I broke those ideas into different parts of the story.
If you want people to understand three different things, give those things three different moments.
2. Your slides should support you, not repeat you
I don’t think everything you’re going to say needs to appear on the slide.
If there’s a paragraph behind me and I’m talking at the same time, the audience now has to choose between reading and listening. I’d rather keep the important phrase, visual or diagram on screen and explain the rest myself.
This is also why I spend quite a bit of time simplifying the actual words on my slides.
In the React Nexus deck, for example, I kept using the word “guardrails.” There was nothing technically wrong with it, but the more I looked at it, the more the presentation started feeling like an architecture document.
Eventually, instead of finding another technical word, I started framing those sections around simpler questions: what happens when something fails? Can the customer recover? Can they safely try again? How do we earn their trust back?
The technical depth was still there. I was just making sure the slide wasn’t doing all the talking for me.
3. Show the idea when you can
Whenever possible, I prefer showing an idea instead of explaining the whole thing with text.
One example from the same deck was around how much complexity sits behind something that looks as simple as a Place Order button.
My first version used text and architecture boxes. It explained the point, but it didn’t really communicate the feeling of it.
Eventually, I made a tiny payment button carrying a huge amount of weight. That visual worked much better because the button itself became part of the explanation. To the customer it’s just one click, but behind that click there’s money, trust, risk and multiple systems that all need to work correctly.
That changed how I think about visuals.
Instead of asking, “What visual can I add to this slide?”, I try to ask, “Can I explain some part of this idea visually?”
Those two questions usually lead to very different slides.
4. Find a visual language, but don’t force it
I like decks where the slides feel like they belong together. The fonts, colours, shapes, illustrations and diagrams don’t need to look identical, but there should be some common language running through the deck.
Finding that language can take time though.
For the React Nexus deck, I initially tried using a developer character. It felt too generic.
Then I created these colourful fluffy characters that I started calling Puffers.
They were cute. Very cute actually.
They also had absolutely nothing to do with payments. 😂
I kept trying to make them fit because I liked them, but eventually I realised I was solving the wrong problem.
Payments already had enough characters of their own: cards, wallets, buttons, shields, error states. So I started using those instead and giving them expressions or personalities depending on what I was explaining.
A nervous credit card could show uncertainty. A shield could represent safety. Characters walking away could show people dropping from a broken flow.
Once I found that visual language, the rest of the deck became much easier.
It also taught me something else: don’t keep something just because you spent time making it. I had spent time on the Puffers. I liked them. They still had to go. 😂
5. Design for the conference screen, not your laptop
This sounds obvious, but it’s one of the easiest things to forget while making a deck.
A slide can look perfectly readable when your laptop is right in front of you and become much harder to process for someone sitting at the back of a large hall. Small text, low contrast, tiny labels inside diagrams and dense code snippets are usually the first things to fall apart.
One simple thing I do while reviewing slides is zoom out quite a bit, or just move away from the screen for a moment. If I can no longer immediately tell what the slide is trying to say, it probably needs simplifying.
The room matters too. A colour that feels completely normal on your laptop can feel very different when it’s stretched across a huge projector or LED screen, especially in a dark auditorium.
For lighter decks, I generally prefer slightly warmer or softer whites instead of going straight to a very stark white. Some shades worth trying are:
#FDFBF2- warm, slightly creamy#FAF9F6- soft off-white#F7F7F5- neutral and subtle#F5F4EF- a little warmer#FCFCF9- very close to white, but softer
For my React Nexus deck, I used
#FDFBF2. It still looked clean and bright, but felt a little easier on the eyes on a large screen.For bigger presentations, you can also plan to preparing both a light and dark version of the deck, especially if you know the venue setup may vary. A dark auditorium with a large LED wall might suit one version better, while a brighter room or projector might work better with the other.
You don’t always need to go that far, but the important thing is to remember that you’re not really designing the slides for your laptop.
You’re designing them for the room they’ll eventually be shown in.
6. Give things space
Not every slide needs to be full.
Some slides can have architecture diagrams. Some can have code. Some can just have one sentence or one visual.
Those simpler slides are useful because they give the audience a bit of breathing room and let important ideas actually land.
If every slide is dense and everything looks equally important, eventually nothing feels important.
In the React Nexus deck, some of the slides I liked the most were actually the simpler ones, where the visual carried most of the idea and I could do the rest while speaking.
A conference deck isn’t documentation. You don’t need to fit everything you know about the topic into it.
You just need enough on screen to help people stay with you.
7. Remove more than you think
This is probably one of the harder parts of making a deck.
Sometimes you create a slide you really like, or spend a lot of time on an illustration, and then realise it doesn’t actually help the story.
I had quite a few of those while making the payments deck.
Some visuals looked nice but didn’t explain anything. Some ideas felt interesting but pulled the talk in a different direction. Some slides were just too detailed for the time I had.
So I started asking myself one question more often:
Does this help explain the idea, or is it here only because I like it?
That question killed quite a few slides. 😂
But the deck got better because of it.
The amount of effort you spent making something has nothing to do with whether it deserves to stay in the final presentation.
And I think that’s really the common thread behind all of these things.
A good conference deck doesn’t need to prove how much you know, how much design work you did, or how many things you managed to fit on the screen.
It just needs to make the talk easier to follow.
If the audience can listen to you, understand the idea, and remember a few important moments after the talk is over, the deck has done its job.
Final thought
I don’t think there’s one formula for making a good conference deck. Some speakers use very visual slides, some use code heavily, some keep things super minimal, and some barely use slides at all.
What matters more is whether the deck is actually helping the audience follow the talk.
Before I call a deck done, this is roughly what I check:
- Does each slide have one clear main idea?
- Is there anything I can explain instead of putting it on the slide?
- Can the important text and diagrams be understood from a distance?
- Are the visuals helping the idea, or just making the slide look nice?
- Does the deck feel consistent without every slide looking the same?
- Are there enough simple slides between the dense ones?
- Am I keeping anything just because I spent time making it?
- Will this still work on a much bigger screen?
- Are there a few moments people are likely to remember after the talk?
That’s pretty much it.
For me, a good deck is one where the audience doesn’t have to work hard to understand what I’m showing while also listening to me. The slides should make the explanation easier, not compete with it.
And honestly, most of the time when I’m stuck on a slide, I come back to one question:
What does the audience really need to see here?
That usually tells me what to keep, what to remove, and whether I even need the slide at all.
I’m sure this list will keep changing as I make more decks, but these are the things I keep coming back to today.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article