Lessons Learned from a Failed CSS Talk

It was a relatively crowded local meetup. I was giving a talk on maintainable CSS, and many people were interested. I'd done my research, made my slides, and practiced. I felt confident.

I got through each slide with solid delivery. I hit all the points I'd laid out. I added bits of humor. For the first time, I felt like a public speaker.

Two-thirds in, I was starting the most important part. I also got stopped. I'd hit the time limit, unable to read the "time remaining" notes someone held up before.

People applauded and gave their compliments. I felt glad that what I'd gotten through was received well. But I was also frustrated. I felt worried I looked amateur and ill-prepared.

I looked over my slides afterward, wondering how it happened. All my info seemed relevant, not excessive. My slides were filled with tips and code examples. How'd I wind up going long?

I didn't see my mistake until the next day. It was a pretty huge one.

I'd treated my talk like a giant article

I'd focused more on my slides than what I wanted to say. I crammed in lots of info, then based my words around that. That's bad, since giving a good talk is less about what's see and more about, well, what people hear.

Articles and slides are great for technical info, but that's not the main point of a talk. A talk is more about telling a story around a topic. Changing people's perspective. Inspiring them to try something else, and giving them the tools for that. My approach was like running a long blog post through a screen reader - informative, but long-winded and missing the point. The two reasons my talk went too long.

All this is painfully obvious in hindsight. So I pulled some useful rules out of this lesson. I plan to follow them for my next talk, and encourage other to as well!

Write your Talk Around a Simple, Key Message

Articles can focus around several points or tips (like this one is doing now!). Talks can do this too, but not as heavily. Mine should have focused more around a stronger, central piece of advice. This would've given it a simpler narrative I could build on and return to as I went.

For example: at one point I randomly mentioned a key takeaway of “keeping CSS specificity low.” Once I said it offhand, I realized almost everything else grew from that point. Yet it wasn't on any slide, and I mentioned it for just a few seconds. Who knows how many people paid attention to it, or saw how important it was?

Rethinking this speech, I would've said this in the first three minutes and emphasized it a lot. Every tip would connect back to it, since they're just different ways to keep CSS specificity low. If my talk becomes a story, "low CSS specificity" is the main character that story is about.

The talk I gave buried this lead. Without that focus to prioritize my slide content around, too many ideas got stuffed in.

Make Slides After the Talk

While preparing my talk, my first move was filling my slides with all the useful info I could think of. This was another mistake - I was adding information before I knew which pieces my talk needed.

Slides shouldn't be first since they're made to highlight the talk, not substantiate it. Your words and story are what people are there for.

• Keep people's attention
• Visually explain tough concepts
• Show some code samples or webpages
• Maybe have some humorous GIFs

One thing slides aren't are a transcript or restatement of your talk. When I did this, it didn't feel like a talk. It felt like my audience and I were just reading some blog post together.

So next time I'll write my talk first. I'll get your story together, add and remove some details, and practice reading it. Only then will I start my slides.

List Resources, Don't Rewrite them

Cold dose of reality time: I know not everyone at my talk was interested. Some were indifferent, some were waiting for the talk they really wanted to hear, a few likely disagreed with and disliked me. I know this since I'm the same. At a recent conference I went to, EmberConf, there were a few talks I was apathetic towards.

All that's fine, and it's fine when people in your audience feel the same. It's just another factor to plan your talk around.

My idea for doing this is listing resources at the end. It lets people interested in your talk dig deeper on their own time, and doesn't draw things our for those who wouldn't want to. It's respectful of their time while still trying to inform and inspire them.

Even better, this comes back to not overloading my talk with extra info. Several slides could have been "Check this out to learn about X" followed by a URL to search. That cuts out almost one-third of my talk time right there!

Show Some Personality

Lastly, if the talk's focus is going to be on the words and story, why not make it more unique to who I am? This got lost before, since articles rarely show much personality. Thankfully, talks are a different story (get it?).

I believe most people have some kind of charm they can use for talks. Whether it's that they're funny, sweet, quirky, humble, eccentric, or anything else. People will likely hear me talk at first for the info, but come back for my personality and (attempts at) humor. Whatever it is for you is worth working into your talk.

My own "charm" I use is self-deprecating humor and obscure anime and philosophy references. Sure, that's not all my personality, but it's what works best for me with most talks. Depending on the group, I may emphasize different sides of who I am. That may seem insincere, but we all have varied personalities. No point in limiting how we express them!

Do I contradict myself?
Very well then I contradict myself;
(I am large, I contain multitudes.)

Conclusion

At the end of that meetup, I was offered to finish up the talk at a later meetup.

I don't plan to do that.

I plan to give a better version of my talk that won't go over with the above tips in mind.

I don't intend to repeat my past mistakes so easily. I'll give the focused, inspiring, and (hopefully) entertaining talk I've wanted from the start.