Engineers present constantly: demo days, fundraising, conference talks, architecture reviews. And most engineer decks fail the same way. The slide gets treated as a document, so it carries a document’s word count at a caption’s size, and the audience reads instead of listening. The fix is not a template or a designer on retainer. It is a short list of constraints, each one checkable, and you can apply all of them to your next deck this week.
- One idea per slide. If summarizing a slide takes a sentence with “and” in it, split the slide.
- Type is the design. One typeface, two weights, and a 40 point floor on body text. Text that will not fit at 40 is text you have not finished cutting.
- Every data slide asserts one finding, and the title states it: “P99 dropped 4.2x after batching”, never “Latency results”.
- Code on slides: 12 lines maximum, 24 point minimum, highlight the two to four lines that matter, dim the rest.
- Dark decks for stages and dark rooms; light decks for bright rooms, weak projectors, and anything sent as a PDF. Never both in one deck.
One idea per slide
Slides are pacing devices, not pages. A slide costs nothing to add, so the constraint is never slide count; it is ideas per slide, and the right number is one. Forty light slides carry a 20 minute talk better than twelve dense ones, because each advance re-earns attention and the screen always agrees with what you are saying.
Two named references set the range. Guy Kawasaki’s 10/20/30 rule for pitch decks: ten slides, twenty minutes, nothing smaller than 30 point. The Takahashi method is the far end: a single word or number per slide, set enormous, advanced fast. Your talk lives between them, and both ends beat the dense middle.
The test is mechanical. Cover the slide and state its point in one sentence. If the sentence needs “and”, split the slide. If no sentence comes, cut the slide. Detail that survives the test but not the slide goes in speaker notes, or in the send-ahead document. The deck you present and the deck you email are different artifacts; Nancy Duarte calls the emailable one a slidedoc, and building one deck to do both jobs ruins both.
Type does the design work
Decoration is where engineer decks go to die: gradient icons, stock photos of handshakes, template flourishes in the corners. None of it communicates. A single sentence set large in one good typeface on a plain background is already a designed slide, and it reads as more confident than any theme. The rules from typography for engineers transfer directly; slides just run them at 10x scale.
- One typeface, two weights. A workhorse sans (Inter, Archivo, Söhne, Helvetica Now) in regular and bold covers an entire deck. A mono for code is the only addition.
- Left-align body text. Centered text is for single statements only. The moment a slide has two lines of prose, rag it left.
- Bullets are a last resort. Four lines maximum, no sub-bullets ever. Most bullet lists are one claim plus three pieces of evidence; make the claim the slide and speak the evidence.
- Tighten the display sizes. At 80 point and above, pull letter-spacing slightly negative and line-height down to about 1.05. Body defaults look loose at display scale.
The 40 point floor
Body text never drops below 40 point. Titles run 60 to 80. A statement slide, one sentence alone on the screen, runs 80 to 120. Kawasaki’s floor is 30; hold yourself to 40 because your deck will also be shown through a washed-out meetup projector and inside a conference recording watched at phone size, and 40 survives both.
The floor is not only about the back row. It is a compression function. At 40 point, a 16:9 slide holds roughly 20 words, so the floor forces the editing that makes slides sharp: the sentence gets shorter, the second clause moves to your mouth, the caveat moves to notes. When something will not fit at 40, the type size is never the problem. The words are.
Field test before every talk: stand two meters behind your laptop. Anything you cannot read from there, the room cannot read at all.
Data slides make one point
The strongest convention for technical slides is assertion-evidence, developed by Michael Alley at Penn State: the slide title is a full sentence stating the finding, and the body is the single piece of evidence that supports it. Not “Benchmark results” but “Quantized inference holds quality to 0.3% of baseline”. An audience that only reads your titles should still get the whole argument.
Then strip the chart until only the point remains:
- One chart per slide. Two charts is two slides.
- One series in your accent color; every comparison series in gray. The colored line is the sentence in the title.
- Label lines directly at their endpoints and delete the legend. Legends make the audience do a join.
- Fade gridlines to near-invisible, drop chart borders, never 3D, never a second y-axis.
- Round in the title, keep precision in a backup slide. “4x faster” on screen; 4.17x when someone asks.
A data slide that makes two points makes none. If your ablation table matters, it gets its own slide with its own assertion title, or it goes to backup.
Code on slides done right
Never screenshot your IDE. The file tree, the tabs, the minimap, and the 11 point font all come along, and none of them are the point. Code on a slide follows the same law as everything else: show the idea, cut the rest.
- 12 lines maximum, 24 point minimum. That allows about 40 characters per line, so re-break lines for the slide. Slide code is display code, not compilable code.
- Strip the scaffolding. Imports, error handling, logging, type ceremony: gone, unless one of them is the point. A comment can stand in for what you removed.
- Highlight two to four lines, dim the rest. Full-brightness code everywhere means nothing is the point. Drop non-essential lines to about 40% opacity and the eye lands where you want it.
- Build in steps. Walking through logic, reveal line groups progressively, and say what to notice before it appears.
What survives the cut is small. A 40 line retry implementation becomes the one decision worth a slide:
# The full loop is 40 lines. The slide shows the decision.
for attempt in range(MAX_RETRIES):
delay = BASE * 2 ** attempt
delay += random.uniform(0, delay) # jitter: the fix
sleep(min(delay, CAP))
Use a high-contrast syntax theme with your deck’s background, not your editor’s pastel one; low-contrast themes vanish on projectors. If your tool cannot highlight code, paste from a renderer like Carbon or ray.so at export size, never at editor size.
Dark or light, never both
Dark decks belong on stages and in dark rooms: they read as native beside code, and they do not blind a dimmed auditorium with a white rectangle. Use an off-black background around #141414 with text at #ECECEC; pure white on pure black halates on projection and makes thin type shimmer.
Light decks win everywhere else: bright rooms, the investor meeting where the deck is a laptop across a table, anything printed, and anything sent as a PDF. They also degrade more gracefully, because cheap projectors lose black levels first and a dark deck turns to mud on one. Choose per venue, keep one accent color either way, and never mix modes inside a deck; when you do not know the room, choose light.
Tools with strong defaults
| Tool | Why it fits |
|---|---|
| Keynote | The strongest defaults of the general tools: good type rendering, restrained templates, builds that do not embarrass you. The safe pick for demo days and fundraising. |
| Slidev | Markdown slides for code talks. Syntax highlighting and per-line highlight ranges are built in, decks live in git, and the defaults are already type-first. |
| Marp | Minimal Markdown to slides. Almost no knobs, which is the feature: it is hard to decorate. |
| iA Presenter / Deckset | Markdown in, typographically safe slides out. Strong choices when the talk is words and structure rather than code. |
| Pitch / Figma Slides | For decks a team edits together. More rope to hang yourself with; delete the theme before you start. |
Whatever you pick, the first move is the same: strip the theme to a blank background, set the one typeface, define the accent color, and only then write slides. Default themes are where the gradient icons come from.
Where to study great decks
Taste comes from exposure, so study decks the way deconstructing great interfaces studies products: name what the slide is doing before admiring it. Apple keynote segments remain the masterclass in one idea per slide; watch how a single number sits alone on screen for ten seconds. Duarte’s slide:ology and Resonate cover structure and narrative; Garr Reynolds’ Presentation Zen covers restraint. Speaker Deck is a browsable archive of conference decks, worth an hour of hunting for the ones that hold up with the audio missing, and the famous seed decks that circulate (Airbnb’s among them) teach narrative arc more than visual craft. The full list, with links, lives on our design taste resources page.
Then apply it. Take the last deck you shipped and run four passes: split every slide that carries two ideas, raise everything to the 40 point floor and cut until it fits, retitle every data slide as its finding, and re-cut every code slide to the lines that matter. Two hours of work, and the deck will be sharper than most of what your audience saw that month. The rest of this series sharpens the underlying instincts: typography, spacing and hierarchy, and motion, which is also the discipline behind restrained slide builds.