Organised speaking – presentation design
I wanted to outline my approach to presentation design, or development as I prefer to call it.
Why do I consider it development? Well, it’s a product that can be manually done & delivered but with the potential to scale to thousands of users, I’d rather the product be easy to maintain & deploy, deliver real value to the users, and keep up with cutting edge developments in the subject. Also, I call it development because now with the use of rmarkdown, I do actually code my presentations.
General presentation design
I’ve read and studied a lot about presentations, some of the biggest influences being:
– Dr. Andrew Abela and the Extreme Presentation Method
– Buck Woody and his fantastic presentation style
– Brent Ozar and his excellent materials for presentations
– Solid fundamentals in presentation training courses (things like INTRO: Intro, Need, Title, Range, Objective)
When I first come up with the idea for a presentation, I write the abstract for it. In the abstract I set out the tone, material covered, and outline who should attend. This abstract is my requirements doc for later me – it tells me whether I’m selling, educating, or entertaining and what I’m doing it about.
In my opinion, you should always write the abstract first as not only can you write more abstracts than you can presentations but it distills the idea down and helps you think of your audience first.
https://gist.github.com/stephlocke/acc1e12f45350b25a3f5
The typical development process
The same sort of iterative dev process you might meet when designing software I apply to my presentations
| Stage | Translation |
|---|---|
| Have idea | Write abstract |
| Build prototype | Write section headers / outline |
| Gain feedback | Get Oz (and sometimes other peeps) to review |
| Develop version | Incorporate feedback into presentation |
| Build version | Make sure the presentation is done before the day |
| Release | Deliver the presentation |
| Gain feedback | Get organisers & attendees to feedback |
| Iterate Develop > Build > Release > Gain Feedback |
Core concepts
Behind the process sits a number of concepts that I feel really help:
- Customer driven: I have a lot of ideas but only I build presentations when they’re requested so I’m only doing the right work
- Build often: I now build my presentations in R using rmarkdown so that I can make a change and rebuild my presentation with ease
- Source control: be able to restore if you make an error or liked an earlier version
- Backups: have them because you’ll need them! I use github, dropbox and rpubs.com for my presentations so that lots of things can go wrong but I can still present
- Be open: I make my presentation source code available online so it can used and critiqued
- Take feedback: I’m not perfect, nothing I produce is perfect, but I always want to be better so getting that feedback is vital
I’ll wax lyrical about using rmarkdown another time and I’ll do a case study with one of my presentations. I think you can apply the dev process and core concepts of strong software design to your presentations, even if you don’t code them. What techniques do you use that differ from or supplement the above?