It's easiest for me to partition the task into: problem, required_output, sample_input, sample_output. And top-down design.

- I write-down in Notepad the rough list of features I initially need.
- Find and solve incompatibilities between features. (repeat this every day)
- Imagine/sketch/write sample input/events, and what the results should be; imagine the flow. Write the rough flow in notepad or paper, or MS Paint.
- Roughly find which portions of the flow need to be optimized or isolated for special R&D, everything else can be freely bloatware on first draft. This narrows-down the details of the flow a lot, as otherwise you'll try to imagine 'the perfect' path - and waste precious time (short-term memory).
- You already see the different object-types necessary for the solution, draft their class/proc-declarations; optionally make stubs. After writing enough declarations, add comments to each class and each method: what it does, what environment is expected, what behavior.
- Chain those stubs to form the solution's draft. It's like a flow-chart, but in code form.
- Start writing the actual code, filling the stubs. Some classes/procs will need to be created in a sandbox, and tested till the module is complete enough to use/process the sample inputs.
- Run the sample inputs/events, gradually implementing more and more corner-cases; gradually adding more sample inputs to test with. Mark with "TODO:" places that need more code for the final product.
- pre-alpha version is ready when all "TODO:" are gone, and you can't find inputs/events that can't be handled.

"Inputs" in the text are all environment/file/memdata/user-inputs/async-notifications.

Short-term memory is precious. Time can be wasted on: improper tools for the task, dealing_with/commenting_on 2-levels-lower details than the current LOD, waiting for colleagues to complete modules you require.
It depends on the person which tools (notepad/pencil/whatever) aid which tasks the fastest. Sometimes the specific mood or task can be easier if approached in another way; so switch tools and approaches when problems persist longer than expected. Immediately put on hold any mundane code (and mark it), if an idea on one of the R&D pieces comes. Go back when you've described or implemented as much of the idea as possible at the time.

I write text on paper relatively slowly and ugly (an accident in soccer..), so directly writing the stubs/declarations in the IDE (and thus not needing to retype them later) is generally the fastest approach for me. When I remember or edit an idea, I'm not wasting time on looking for empty space on paper and ways to link the new text/code to the existing one, I directly insert in the editor, making use of Intellisense - to keep my classes/instances/procs have self-describing long names. On paper, by the time I write those long descriptive names or any abbreviates forms of them, I'd have forgotten portions of the solution or code-environment. Forgetting those fragments is a major productivity killer.
UI and things like database relations are quickest for me to sketch in paper. Non-trivial memory/LL/algo operations also are often faster on paper (producing sketches like the pages szecs scanned).

Overall, by coding the project in top-down fashion, I usually save-up enough time to try all approaches when a sub-problem persists. If it persists too much, go back to implementing/polishing the mundane/existing parts for a while - ideas often come soon after the context-switch.

For problems I need to really think about and get a good mental image of I typically do a combination of sketches (with my 21 inch Cintiq + photoshop) and notepad, or notepad++ for brain-storming.

For most of my work, however, I just dive right in. It really depends on how well I have a mental handle on the problem at hand.