That got me thinking. What do I do? I'm more a Jaimee-Talker, but I don't really do a single idea in a talk that often. I have a note in the Notes app with all my talk ideas where, every time I encounter a problem or question, and every time I e.g. find myself answering a question on Stack Overflow or at work, I make a note of it.
I try to group them by topic, and that usually quite naturally turns into a way too long talk outline. Then when it's time to come up with a talk, I pick the choice bits out of one or more of these outlines, and make that my outline, sometimes changing the focus. E.g. once I had the mandate to add a missing beginners talk on Quartz to a conference, so I took the most basic, most practical graphics issues from my notes, prefixed them with a general tutorial on how CoreGraphics is organized and that was my initial outline.
Then I built a first rough slide deck based on those notes and just started holding the talk using Keynote, with the audio recording function on, in the privacy of my own home. Sometimes, once the talk has advanced a bit, I even (similar to Jaimee) set up my iPhone or iPad to record myself.
So, how does a talk advance? Well, its simple. First and foremost, I make notes for every slide about the things I've said. Also, at some points giving a talk, I will get stuck. Or I will repeat something Ive already said earlier. Or I'll explain something in words that would really need an illustration. At that point I drop into Keynote and either re-arrange the slides, or do a first rough illustration.
Once I've done this a few times, the talk will feel much more fluid, but will be running horribly long. So I try to do a full run-through without interruptions and time it. Once I have my time, I'll try to find things I can cut and mercilessly cut them. Things that feel like a detour, or boring, or too trivial. Things that the intended target audience would know already. But sometimes I also realize that I haven't explained something that needs explaining and add a slide.
Then I do the talk again. Rinse and repeat, until the timing and flow is right. When the slides have stopped moving and disappearing, and I'm happy with what's in the talk, I'll start refining the illustrations. Adding builds that reflect my description. Usually that on one hand forces me to go through these slides at the (slower) speed of build, but it also shortens my descriptions very much, so often it evens out.
If it doesn't, I might have to cut some more slides, or find a way to simplify what is there to make it go faster.
As you can tell, this is an approach best suited to more technical talks. More philosophical talks sometimes can be analyzed enough that this approach works. Other times, they're more like stories, making them harder to re-arrange and to cut out stuff. I generally still use the same approach, but it doesn't work as reliably. What can I say, it's a work in progress, and I'll work at sucking less at the not-a-story-not-technical-either kind of talks as I can.
I haven't mentioned the title yet. Usually, it comes at the end. I have a working title (e.g. Memory Management Fundamentals), and then look at what is actually in my talk and pick a better name (e.g. On Graph Paper and Memory).
Sometimes, I need to provide a title when I sign up as a speaker. As I already have the notes, I'm usually pretty good at picking a title that works. Sometimes they let me change it afterwards. Sometimes they don't, and I go for that title with a byline that narrows it down to what the new title would be. (Dont put a different title on your first slide than is announced in the programme, attendees won't find you)
One thing I sometimes do in the end is, I record myself doing the final talk (with the iPhone camera or whatever) and watch myself doing it, watching out for how I look. Am I scratching my nose? Do I say umm a lot? Then I try to remember to turn that down.