Presentations/ Professional Development/ Syndicated

How I Architect A Technical Slide Deck

, , , , , , , 2 Comments

Each presenter I know has their own style for developing ideas, organizing their message, and delivering it.  My only aim in this post is to explain my process and present the case for why I follow this new tack.  I am not hear to cast derision on any others’ methods, style, and content.

I’ve been reading Garr Reynolds’ excellent book on building and providing presentations, Presentation Zen, for a year now (sorry Buck Woody, but non-fiction and business books in particular are not in my main reading line-of-sight.)  Though only 3-5 chapters in I’ve already taken away from the book, some key points that have dramatically changed how I work through the idea-to-delivery process.  I’ll outline some here for you to take into consideration or deride as you see fit.  I’m just her to humbly pass along what works well for me at this point in my experience as a technical speaker.

Oh, and keep in mind that this is all coming from someone who never intended to get up in front of a group of people of any size to talk, jabber, or make a general fool of himself at any point in his life – a man who, as a child placed third in a field of three for an Optimist Club oratory contest that to this day he doesn’t know how he found himself in.  A guy who constructs run-on sentences that preceded this one.  No, if it was not for an individual slated to play game show host for a group of 2,000 at a Professional Association for SQL Server Summit in 2004 dropping out at the true last minute I would probably not be here now.  Eight years of cracking jokes, wearing kilts, tripping over words, succumbing to presentation-death-by-bullet-points, and reading right from the slide deck led to this; the next cycle in how I evolve as a technical presenter.

No Bullet Points

I’ll even expand on this a bit more:  not only no bullet points; a minimal use of words on the slide.  Unless you’re conveying information through a graph or chart or presenting data in some form of matrix I no longer place the words that come out of my mouth onto the slide deck.

Why is that?

When I was younger I used to read and listen to music at the same time.  For some reason in my youth I was able to focus on my reading without hearing the background music as a distraction.  I think much of this has to do with learning how to not listen as we grow out of our childhood.  Much of it has to do with how our brains process information.  Many, if not most adults that would be interested (okay, perhaps not interested, but in the line of fire) of a technical presentation have lost the ability to Read, Listen, and Comprehend simultaneously.  Just as is the case with manufacturing and engineering (Cheap, Fast, and of High Quality) you get to pick two out of those three.  Unfortunately when it comes to reading, listening, and comprehending our individual brains do not necessarily get to pick which two.  The Presenter is sadly at a deficit when it comes to accommodating this trait of human reasoning though because of the individuality of the situation.  It’s impossible to craft a presentation (and by that I mean deck and discussion) that will work for everyone in the room.

That is why the Presenter needs to make the largest concessions to make this work for everyone in the audience by removing the one of those three components.

When someone is presenting straight from a deck full of words and even reading the deck practically word-for-word, the comprehension is lost.  The audience is not only unable to take in the message from the slide – but their also incapacitated in comprehending the verbal message.  This is why, with the exception of a few targeted slides in my presentations which I get to next, I eliminate all words from my deck other than a title explaining what I’ll be discussing for the next few moments.

So what do bullet points have to do with this?  Bullets are the entry drug of wordiness.  You don’t add one bullet… ever.  There is a reason guns hold more than a single bullet and that’s because just one never seems to be enough.

Objectives v. Agenda

What you hope to get across in your presentation are your Objectives.  How you intend to get there is your Agenda.  The two, while inextricably bound to one another, are not the same.  These are the two slides I have in each deck I now build.  These are also, with the exception of my About Me slide, the only ones I tend to allow myself to read from.  I still try to keep word count to under 5 words per line though and expound on what is presented on the screen without talking over what is on the slide when I do.  Again, the words in your deck are meant to guide the Presenter and the audience in their discussion – not replace the discussion with a sort of 3D Audiobook World Tour.  I place these slides one after the other in my deck and may occasionally find myself repeating the slides throughout the deck with the active portion of what I want to discuss highlighted in some manner.

When it comes to an Objectives count, my main goal in every single presentation I now deliver is to have the audience members walk away with gleaning three key points from the time we spend together.  I’m referring strictly to presentations under 90 minutes long.  I would scale this accordingly depending on the length of our conversation.

Reading from the Deck

See No Bullet Points

Typing in Presentations

With limited deviations from this goal I avoid typing in my sessions.  I prefer, when demonstrating code of any kind, to have the code built, and in the case of Microsoft SQL Server loaded as a template and organized in the Template Explorer of the SQL Server Management Studio application used to interface with the SQL database(s).  There are times however – when replacing parameters in your code with values of interest for the discussion at hand or to answer an ad hoc question from the audience – that a presenter may find that they will type in a presentation.  That is acceptable and expected.

Links

I tend to allocate a slide in my deck to informing the audience that there is a link on my website for all my technical presentations.  I utilize Go Codes in my WordPress-backed site to point presentation attendees to the dedicated page on my site using the following linkage:  http://thesqlagentman.com/go/presentations. I order these in descending date on the site so that they can not only download the current presentation materials that I wish to make available (more on that next) but that they may also download any of my previous presentations’ materials I’m making public.  I place this early on in the deck so the audience knows they only need to take notes on what I say, not what is on the slide, or available as handouts, or in the scripts.  If there is anything in my presentation I don’t intend to release as a download I’ll note that when we talk.

Slide Deck v. Handouts

The deck should not replace the conversation; it should augment the conversation.  That is not to mean that the presentation should only hold value for those whom attend, but it is only going to convey a part of the discussion.  I prefer to go the route to providing handouts in the downloads rather than the slide deck.  In the past that was not the case.  I would supply a PDF version of the deck as much as to eliminate the ability to see my speaker notes as to avoid possible plagiarism.

 In closing…

Do I expect these pointers to work for every presenter in every situation?  No.  Odds are there will be times when I deviate from this structure too, however this is the evolutionary step I’m taking to (hopefully) make myself a more effective and interesting Presenter.  You may have noticed I’ve tried to make this about having a conversation. Throughout this post I’ve made an earnest effort to label my time with an audience during a presentation as such because a conversation, in my opinion, is always more interesting and valuable than a lecture.  In a conversation all parties should walk away learning a bit more.  So add to this list the desire and structure to engage the audience and make the time together more dynamic than a standard lecture.  Particularly when discussing dry subject matter or topics highly technical in nature.