How to Structure a Good Technical Presentation

Firstly, look at the Assertion-Evidence presentation strategy, it is research based and much more trusted than I am. But I think I also express things that this doesn’t, specifically telling a story with a presentation and aesthetic discussions.

The big takeaway

Start from the end of the presentation. What do you want the audience to take away from the presentation? Then go backwards. What slides do you need for the audience to understand that takeaway? (and possible to believe it?)

• Rolf van Wegberg

You are giving a presentation for a goal. Structure that presentation to meet that goal.

Technical presentations are a unique beast that are often oversimplified

A presentation is a fundamentally linear experience for the audience (unlike a paper) and you are fighting against a very tight attention budget per person over time. Unlike a paper, where you can reference sections, figures, and tables ahead and behind your current position, use footnotes for branching arguments, expect your reader to read and re-read, your audience will see your presentation once and in the order you give it. Therefore you must structure your talk and slides in a way that unambiguously conveys the message of your presentation and sufficiently convinces your audience about your argument (or at least make them convinced enough to read the paper).

Your primary budgets are complexity and time. You have probably heard statements about how much text to put on a slide, this is just a proxy for complexity: you can have a slide with 0 words that is still far too complex. Additionally, the ordering of your slides makes a huge impact on the perceived complexity of each slide (which, for our purposes is a part of the complexity budget but affected by ordering). As a presenter, it is absolutely critical that your audience understand what you are saying, why you are saying/doing it, why you are speaking at all, and how it affects them. Consequently, expect any presentation to take about 1 hour per the talk’s duration of minutes + 10 hours to complete and prepare. If you’re giving a talk again, this is probably closer to about 5 hours per minute.

So, let’s get in to how to structure them.

Structure of a technical presentation

I’m going to switch interchangeably between three different mental models of what I’m talking about. They are all pretty much equivalent, but certain abstractions lend to better language explaining certain aspects of what I’m saying. For background, you’re expected to know what a tree looks like, what a stack is (computer science sense works best), and how a math proof is structured (like from highschool geometry) (working with code is also sufficient). I’ll describe the analogies as we run across them.

Imagine you’re drawing a tree that someone has pre-drawn the roots for. You cannot lift your pen off the page, you must start from the roots and end at the roots, and you only have a small amount of ink left in the pen.

Do you immediately start drawing the leaves of the tree? No! Not only would it not make sense, but you’ll run out of ink or space well before you have any time to draw the trunk or branches. Do you draw little branches right at the roots either? Again, no (although in reality trees often do have these, picture a 2nd grader’s drawing of a tree)

When you draw a tree, you draw a nice strong trunk that branches out before it has any leaves on it, like the one below. You should think of this as your argument structure for your presentation.

You assume your audience has some kind of background. Depending on where and why you’re giving the presentation, this could be different. At a conference, you expect technical individuals with some expertise but, at a stakeholder meeting, you should expect less technical knowledge. Know where you’re starting from before you begin.

From your background, you first need to establish a solid trunk of the presentation. This can only be grounded in the background knowledge and needs to be a continuous argument. This should be something that sets the stage from what your audience is expect to know into what you want to talk about, gives them reason to care, and explains concretely why you’re giving the presentation. For example: This is my talk on presentations. I’m sure you’ve all seen a presentation before, and I’m sure you’ve all seen bad presentations before. Good presentations are great because they convey a lot of information quickly. In this work, I’ve examined how good presentations are structured.

Once your audience knows what you’re talking about and is convinced to listen, then you can start making the trunks of your argument. This can be anything like background/related work, methodologies, experiments and results, etc. The arms of your tree should be self-reliant in themselves, they shouldn’t really have too much inter-connected detail between them. If you find this is the case, separate them out as much as possible and really boil down why you’re trying to show what you’re showing. Reorder your slides so each section is as self-contained as possible.

To think of this self-containment, we’re going to use a stack. When you want to switch into a more technical/detailed area (e.g. all your branches), you are going to push down into the stack. This is how your brain works - when you’re having a conversation and someone mentions their mother, you take a second and ask how she is, then you continue on from where she was brought up naturally. Do the same in a presentation

You have just described the overall plot of your slides, now give clarification to the background by pushing down into a background section. In this stack frame you talk about all your background material, and keep it as self sufficient as possible. If something requires more detail, push further down into the stack or, equivalently, start drawing a twig onto the tree. For small, self contained interjections (that are absolutely necessary to the presentation) you can do a small push or draw a leaf. When you’ve finished with what your current stack frame is talking about, you can pop up back into the previous point you’re trying to make, now with a new piece of information your audience should believe.

This self-containment is important because your audience has a very finite amount of attention and everything they need to keep track of takes up space. When you are trying to argue something, all you really care about is that they believe you, but for them to be convinced they need a series of arguments prior. Each of these arguments takes up space. So you tell the audience your assertion (this takes some mental space) and then push into the body of the argument. Now you give the audience the full argument (this takes a lot of mental space). Hopefully they believe you. If they do, now they can discard all the argument pieces and just retain the conclusion. At this point, you pop out of the argument, making it clear to the audience “you can forget those arguments now, just remember the conclusion”. This is true and important for every stack push you make, be it into a branch, twig, or leaf. Every push down should be necessary to complete the argument that you just pushed out of.

This may remind you very much of a lemma in a math proof. If you’ve ever seen a long math proof (a large code base also has this structure), you know the structure of lemma, lemma, lemma, …, proof! (or function, function, function, main!) A presentation’s core argument is no different, it’s just ordered a little different. Again, your audience can’t go back and re-read the lemma, they need to know its proof as it appears, like how good math professors lecture. A good math lecture will state the goal and then work until a smaller, new, often repeated problem appears. They’ll then generally solve that sub-problem in a lemma and then pop up and apply the lemma to the proof argument. Similarly, your drawn tree will have a lot of similarly structured branches. Each of them gives its own shade though :).

Okay, so let’s tie this all together, how can you apply this? Start with the big question: what do I want my audience to get out of this presentation? what’s the reason I did this work? what does it show? Everything in your presentation should, in some way, answer this question. If you can’t answer this question, ask someone who knows your work decently well but doesn’t have their head stuck in the weeds to help you answer this. It’s not always easy to come up with a good answer, don’t be ashamed. But, the answer should be easily understandable by people who don’t know the work well, once you have the answer.

So, you have your answer, now come up with answers to questions that will inevitable be asked by people when they hear your great claim.

• Has this been done before? Why did you do this in the first place?
• Are your methods sound? Why did you answer the problem in this way?
• What sort of data did you collect and why does it convince you you’re right/better?
• What kind of limitations does this specific work have?
• Is your work sufficient to solve the problem or does more work need to be done? The answers to each relevant question should be its own branch off your tree, its own stack push, and its own lemma. Obviously, you’ll have to present some narrative that flows, e.g. the glue code between your stack pushes, but that’s pretty easy. Come up with answers, and then start seeing what needs to be said to convince your audience of each answer and recursively going to see if additional stack pushes/sub-lemmas need to be made. Assume a reasonable competency in your audience and remember you have a finite amount of time, you don’t need to explain every detail but enough to convince them that every detail can be explained.

You will eventually get an outline, like the ones you used to make for book reports, and each bullet will be its own slide (small leaves can be just points in slides). Here’s an example: Goal: chocolate is a personally very addictive substance

• You may have heard about chocolate from people on the street, maybe you’ve heard it’s the most addictive candy (contextualize it)
• Previously, addictiveness of candy has been measured to see which is the most addictive
  • Study A did this experiment and found chocolate to be in the top 10, but wasn’t any more accurate
  • Study B also found this out, but they use an older variant of chocolate
• I decided to see how few times I could eat chocolate before I could no longer refrain from taking it
  • Specifically, if i can go 2 weeks without using again i will consider myself not addicted
    • This is my definition of being addicted, and is a reasonable benchmark
  • if this takes more than 12 weeks, I will consider it not addictive
  • my health is of less concern than the scientific merit of this project & I have IRB approval
• It turns out not very many times
  • I took it once and was able to refrain from taking it for 2 weeks
  • I took it again and could no longer control myself
    • I broke into my lab safe to access the chocolate, which required me brute forcing a 4-digit lock combo.
• It may not be the most addictive substance
  • I could have tried rock candy too, but I couldn’t decide what color to pick
  • it is more addictive than ice cream, which I resisted 12 weeks in a row
• I am now addicted to chocolate and have eaten it every day for a month

Now, take this outline and make a slide for each bullet. Note, that the slide titles should be the takeaway for your slide. Fill in the necessary detail on each slide to convince the audience of the title (maybe with a little bit of context from previous slides) go back through a few times and put in the “glue” slides that are needed to make it flow.

Boom, you have a very solid start to a great technical presentation!

Additional comments that don’t fit elsewhere

• Every slide title should tell the audience why it’s there, preferably with some takeaway. Do not tell the audience what they’re seeing. They can see the contents of the slide themselves. If they can’t decipher the contents on their own it’s a bad slide already. What they don’t know is what is coming up and why you put that slide where you did.
• Animate contents of slides in, pretty much no matter how little there is on the slide. Whenever you show a new slide, your audience will tune you out, read the entirety of the slide, then continue listening to you. Only display what you are okay with them looking at instead of listening to you. Ideally, this should be paced at the same pace you’d write/draw the slide up on a white board.
• Your audience will always notice every detail in your presentation, but not as a whole. You have orders of magnitude more eyes on your presentation as you’re giving it than you have given it. Do not neglect little details
• Alternatively, your audience comes in with a bunch of different prior experiences and therefore default understandings. If you are going to use a technical term or a metaphor, it needs to be well defined.
• unless you absolutely have to, do not put tables in your slides. Pictures/graphs/diagrams are infinitely better. Find out what you want your audience to take away from the table and display it in a different manner. Put the table in the paper, not the slide deck.
• The same question can have lots of different answers try to gauge (or even ask) what kind of answer the asker wants. For example, the question: “why did you choose to rewrite this section of code?” can have at least two intended asks and answers. 1. the engineering answer - the previous code was buggy and it was quicker to rewrite it than to debug it. 2. the academic answer - the previous code lacked the abstractions that we are trying to make on our new model. These answers are both correct but answer a different flavor of question.
  • PS: It’s okay to say “I don’t know”!
• You should never say “umm”.
• This advice was talking about conference presentations (typically ~12 minutes) with the intent of a lean presentation. So, for a longer presentation like a (master’s) thesis defense, course project, etc., you might not trim so much as one of your takeaways should implicitly be technical prowess.