How I Built My Teesside Keynote

Apr 16, 2026

First slide from my Teesside keynote

I thought it might be useful to write up how I put together my recent keynote at Teesside.

What started out as "make a good slide deck" ended up involving more than just the slides. By the end I had the slides themselves, a rehearsal workflow, a voiceover and transcript pipeline, several export paths, and finally the standalone version now live at AI in Higher Education.

In hindsight that is probably not surprising. The talk itself was about infrastructure, dependence and control in higher education, and I found myself being increasingly unwilling to treat the presentation as something trapped inside a single tool.

One practical point worth mentioning is that I used Codex, Claude Code and AMP to do a lot of the leg-work around the workflow. I tend to use all three for different things. In this case that gave me more time to develop the actual content of the keynote myself.

Starting Point

At the centre of the whole thing was the argument of the keynote. The presentation needed to make a clear case about AI infrastructure in higher education without becoming vague, overblown or full of fashionable language.

That meant I spent a lot of time not just on slide design, but on wording. I kept tightening phrases, removing repetition, adjusting emphasis, and trying to make sure the slides worked for spoken delivery rather than just silent reading.

I have found this quite often with talks. If a slide only works when you stare at it for a while, it probably is not ready yet.

Rehearsal Came Very Early

One of the first things I wanted was a better way to practise the talk.

I exported slide images, turned them into an Anki deck with the notes on the reverse side, and also generated a PDF version that worked well on a reMarkable. That was useful because the talk stopped being something I only interacted with inside the deck editor.

I could run through it in different contexts, annotate it, mark up awkward bits, and then feed those changes back into the source.

That quickly became the pattern for the whole project:

Draft the slide
Export it
Rehearse it
Notice what felt clumsy
Go back and improve the source

That sounds obvious, but for me it changed the quality of the talk quite a lot. The rehearsal process was shaping the argument rather than just testing it.

Marking Things Up Properly Helped

Another useful part of the process was working from marked-up versions of the deck rather than pretending I could hold all the required changes in my head.

Once I had PDFs I could annotate comfortably, it became much easier to spot weak transitions, over-explained slides, and phrases that were technically correct but not quite right for delivery.

Quite a lot of the improvement came from small changes of that kind. A better phrase here, less text there, a stronger opening line, a cleaner distinction between two ideas.

None of those changes looked especially significant on their own, but together they made the talk clearer.

Adding Voiceovers

One useful step in the project was deciding to make the spoken version part of the presentation itself.

I added per-slide voiceover recording, playback and deletion, together with duration information and overall runtime indicators. I also moved the deck onto stable slide IDs so that audio stayed attached to slides even if I reordered or changed things.

Once I had recorded the whole talk, I could transcribe it and store the transcripts alongside the slides. I then had not just a deck and some notes, but a presentation with a proper spoken layer attached to it.

That mattered for a few reasons:

it made rehearsal easier to do properly
it made it easier to hear where the pacing was wrong
it exposed slides whose wording did not quite support what I wanted to say
it opened up the possibility of captions and timed playback later on

I have increasingly found that if I am serious about a talk, I need to hear it, not just read it.

Notes and References Mattered More Than Usual

Because this keynote was making claims about AI companies, infrastructure concentration, governance, procurement and institutional dependence, I wanted to be quite careful about the factual spine of the talk.

So I spent a fair bit of time going through the content and making sure the claims were sharp but still defensible. That included tightening wording, checking references, adjusting units and terminology, and making sure the speaker notes were actually useful.

I also ended up drafting material around the talk rather than just the talk itself: how it should be introduced, how Student Voice AI should be described in that setting, and what kind of questions might make sense afterwards.

For me, that all sits inside the same piece of work. A keynote is not only the slides. It is the whole structure around the talk.

Exports Became Their Own Problem

Once the deck had to exist in several forms, export quality became a separate part of the project.

I needed the presentation to work as:

the live deck
exported PNGs
PDFs
PPTX
rehearsal material
a standalone web presentation

As soon as you have that many outputs, you start discovering a familiar set of problems. Stale assets. Alignment differences. Borders looking slightly wrong. Slides that are fine in the live view but do not export properly. Components that look balanced in one place and awkward in another.

I spent quite a lot of time on exactly that kind of work.

Some of it was straightforward, like making sure old slide PNGs were cleaned out before new exports were generated. Other parts involved small adjustments so exported output matched the live version more closely. I also simplified some slide layouts once it became clear that they were too fragile across different output paths.

None of that work is especially glamorous, but it made the difference between "I have a deck" and "I have something I can trust".

I Wanted the Talk to Publish Well

At a certain point it stopped making sense to think only in terms of slides. I wanted the keynote to exist as a standalone public presentation.

That meant building a version with narration, captions, transcripts, previews and mobile support, rather than just throwing a PDF online somewhere.

This is where the project broadened quite a bit. I had to think about the presentation almost as a small product:

Would the audio behave properly?
Would the slides auto-advance in a sensible way?
What happened on slides with no narration?
Did the captions feel readable?
Did the whole thing behave well on a phone?
Could it be synced safely into the public site repo?

That final question ended up mattering as well.

Mobile and Final Polishing

The last stretch of work was mostly about polishing the standalone viewer.

I adjusted mobile layout, sorted out focus behaviour on the opening overlay, improved the order of information on smaller screens, and generally tried to make the standalone viewer feel intentional rather than like a rough export.

I also had to be careful when syncing the built presentation into the deployment repo. That is one of those things that only sounds boring until you make a mistake and realise you have been a bit too aggressive with a sync command.

Again, this kind of work is easy to dismiss when you are close to the finish line, but it is part of what makes something actually usable.

What I Ended Up With

By the end, I no longer really thought of it as "the slides for a talk".

It had become:

the source of truth for the argument
the source of truth for the notes
the source of truth for the narration
a rehearsal system
an export system
and finally a publication system

That is probably the main thing I learned from doing it this way. If you build the workflow carefully enough, the gap between writing, rehearsing, delivering and publishing becomes smaller.

Final Thoughts

What I like about the final outcome is that the method ended up fitting the message.

The talk itself is about infrastructure, concentration, control and dependence. In the process of building it, I found myself wanting more control over the presentation infrastructure too: structured source content, stable IDs, preserved transcripts, multiple exports from one source, and a standalone public version that did not depend on a black-box presentation platform.

So in the end I did not just build a keynote. I built a workflow around one keynote.

If you'd like to see the finished result, you can view the live keynote on AI in Higher Education or read my short keynote recap.

Related: