Case Study 2 — Deep Dive: When the Whole Deck Is the Problem

The first case study fixed one slide. This one fixes a habit. A composite engineering deck shows that the worst slide problems are structural, not cosmetic — and that the "deck that's secretly a document" is the disease behind most of them. (Fictional but realistic.)


The setup

Raj Patel — the backend engineer whose README makeover you'll meet in Part V — has been asked to give a 20-minute internal talk: should the team adopt a new message-queue system? He has done the research, run a prototype, and reached a clear recommendation: yes, with one caveat. He builds a 31-slide deck the way he's always built decks — open the company template, paste in everything he knows so the deck is "complete." When he rehearses it for a teammate, she stops him at slide six and says, "I've stopped listening. I'm just reading."

Here's a representative stretch of Raj's deck.

❌ Deck excerpt (described). - Slide 1: "Agenda." Six bullets: Background · Current Architecture · Problem Statement · Options Considered · Recommendation · Q&A. - Slide 2: "Background." Nine bullets of history about the current system, in 16 pt. - Slide 5: "Options Considered." A table with five columns and seven rows comparing four queue systems across seven criteria, in ~11 pt — unreadable past the front row. - Slide 9: "Architecture." A diagram with nine boxes and fourteen arrows, all shown at once, with a 10 pt legend. - Slide 14: "Performance." A 3-D bar chart, six rainbow bars, legend in the corner, y-axis starting at 200, two corner logos. - Slide 22: "Recommendation." Five equal bullets, the actual recommendation third among them. - Slide 31: "Questions?" A blank slide with the word "Questions?" centered.

Every slide is dense. Raj's plan is to read each one and elaborate.

The diagnosis: it's not the slides, it's the artifact

Tempting to fix this slide-by-slide — shrink the table differently, recolor the chart. That misses the disease. Raj built a document and is planning to perform it. Every specific failure is a symptom of that one choice:

  • The agenda-first opening spends the most valuable real estate on a table of contents instead of a hook.
  • The nine-bullet "Background" exists because Raj feels the deck should be self-contained — a reader's instinct, not a speaker's.
  • The five-column table and the nine-box diagram shown at once are reference material dumped onto narrated slides; they belong in an appendix or a build, not in the flow.
  • The 3-D rainbow chart with a truncated axis is pasted from his analysis tool, not rebuilt for projection — and the truncated axis quietly distorts the comparison.
  • The five-bullet "Recommendation" buries the one thing the meeting exists to decide.
  • The "Questions?" closer wastes the slide that's on screen longest (all through Q&A) on a word everyone can infer.

The teammate's complaint — "I'm just reading" — is the read-or-listen threshold announcing itself. Raj doesn't need 31 prettier slides. He needs to decide, slide by slide, what one point each makes, and to move everything else into his voice, an appendix, or a written leave-behind.

The redesign: a habit, not a slide

1. Separate the artifacts. Raj writes a two-page decision memo (the document) for people who want every detail and for those who miss the meeting. Freed of the obligation to be complete, the deck can become a set of visual aids.

2. Open on the point. Slide 1 stops being "Agenda" and becomes an assertion: "We should adopt RabbitMQ — it cut our tail latency 4× in the prototype, with one tradeoff to manage." One striking visual: a before/after latency bar. The room knows in ten seconds where this is going and why to listen.

3. One point per slide; rebuild the visuals. - The nine-bullet "Background" collapses to one slide with the only point that matters: "Our current queue drops messages under peak load — that's the problem we're solving," over a simple diagram of the failure. - The five-column comparison table moves to a reserved reference slide at the back (dense is fine — it's an appendix Raj flips to only if asked) and is replaced in the flow by one assertion slide: "Of four options, only RabbitMQ met all three must-haves," with a simple checkmark matrix showing just the three must-haves. - The nine-box architecture diagram gets a build animation: each component appears as Raj narrates it, so the system assembles in the audience's understanding instead of hitting them as a fourteen-arrow tangle. (Chapter 32 goes deeper on the diagram itself.) - The performance chart is rebuilt: flat bars, axis at zero (revealing the 4× honestly), one accent color, direct labels, 28 pt, logos gone. - "Recommendation" gets the one decision as its title — "Adopt RabbitMQ now; revisit if message volume 10×es" — with a tiny two-line visual of the recommendation and its one caveat.

4. End on the takeaway, not "Questions?" The final slide repeats the recommendation assertion, so it's on screen — reinforcing the ask — throughout Q&A. (A trick from Chapter 18.)

5. Audit with 10/20/30. The rebuilt narrated deck is ~12 slides making ~10 points (plus a few reserved reference slides held for Q&A), deliverable in well under 20 minutes, every word readable at 30 pt. It passes the spirit of the rule even though it's not exactly ten slides — because the rule means few points, tight time, big type, and a build-animated, visual-heavy talk legitimately runs a few slides over while honoring all three.

The takeaway

The fix wasn't cosmetic and it wasn't slide-by-slide. It was a single reframing — this is a visual aid for a talk, not a document I read aloud — from which every specific repair followed: separate the artifacts, open on the point, one point per slide, rebuild visuals for projection, hold dense reference material in an appendix, and end on the ask. When a deck feels broken in twenty places, look for the one wrong assumption underneath. Usually it's the same one Raj made: building to be read instead of to be seen while someone talks. Fix the assumption and the twenty problems fix themselves.


Back to: Chapter 30 · Exercises · Quiz · Key Takeaways