For Students‎ > ‎

Preparing Good Slides

I will perform a magic trick: even though I have not yet reviewed your slides, I am going to give you feedback on them! These tried-and-true "Tips for Slide Success" have been distilled from years of watching (and creating) bad slide presentations, so, enjoy!

Number one rule: Use slide numbers that your colleagues (or the audience) can refer to when giving feedback!


  1. Aim for a graphical element on every slide, if possible. That's often impractical but it is an ideal to shoot for. Remember slides are meant to accompany your talk, not to be read standalone.
  2. Especially when showing graphics, use the full slide real estate. Crop away the unnecessary parts of the image and expand the rest to fit.
  3. Graph axes should be large enough to be read.
  4. You should be able to indicate a point on the graph and explain it. Better yet, include an animated call-out to do so.


  1. Top level bullet text should ideally be 1 line; at most 2. Second level bullets even shorter.
  2. No third level bullets, ever.
  3. If a given level of bullet hierarchy has only one item, ask yourself why.
  4. Use concise and incomplete sentences. Omit articles, verbs, whatever—minimize word count to convey the point, and use Strunk & White to find more concise, active-voice verbs. (Corollary: If something is not a complete sentence, it should not end with a period, so there should generally be few or no sentence-ending periods in your slides.)
    Before: Using fuzz testing in the autograder makes it difficult for students to "game" the tests [15 words]
    After: Fuzz testing thwarts "gaming" tests [5 words]
    (If the slide/bullet is obviously about autograding, you can omit that word. 'Thwarts' is an active voice verb that replaces 'makes it difficult for [someone] to…' The thesaurus is your friend.)
  5. Tersify references (if you must include them) by eliding obvious things. 
    Before: Matthies, Christoph, et al. "How surveys, tutors, and software help to assess Scrum adoption in a classroom software engineering project." Proceedings of the 38th International Conference on Software Engineering Companion. ACM, 2016 [232 char.]
    After: Matthies et al. "How surveys, tutors, and software help to assess Scrum adoption in a classroom software engineering project." Proc. 38th ICSE, 2016 [148 char.]
  6. The slide's title should be its main message, using rules above to tersify it.
  7. Remember that under-saturated colors, such as orange and lime, may wash out in bright lighting or on older/less powerful projectors. Use these colors for subtle accents, for example, to shade a cell of a table or part of a diagram you want to call attention to. For text that needs to be highly emphasized, use saturated colors like fire engine red, royal blue, etc.


  1. Don't use Arial, ever. It's a "screen-friendly" but typographically deficient knockoff of Helvetica, which you should use instead if you want a sans-serif font.
  2. Don't use Comic Sans, ever. In a talk, it's not folksy and informal, just stupid-looking.
  3. No text smaller than 22pt. If the text "isn't meant to be read", it shouldn't be on the slide unless it is there to prove a point, in which case it should be unreadable in the extreme (e.g., 50 lines of 8-point convoluted program code to demonstrate that students often submit tangled solutions to simple problems). If the text is meant to be read, it needs to be readable by people in the back row. No one will download your slide PDF in order to read something they missed during your talk.


  1. On a busy/complex slide, use animation builds to direct the listener's focus as you speak. (Better: make the slide less busy.) But: Use animations only to improve clarity, not to "add pizazz." 
  2. Use slide numbers, both to allow colleagues to critique your dryrun and audience members to refer to slides during Q&A.
  3. Short talks (<= 20 minutes) shouldn't need an outline; their organization should be self-evident.
  4. The "Conclusion(s)" slide should be last. Otherwise it's not actually a conclusion.

Final check

  1. For every slide, ask yourself: How would the presentation suffer, specifically, if this slide were deleted? If there isn't an immediate and crystal clear answer, delete it.
  2. Repeat #1 on each slide, replacing "slide" with "bullet".
  3. Repeat #2 on each bullet, replacing "bullet" with "word".