I find the best bet is to first come up with a few paragraphs that explain the application as if you where writing it for someone else. This will help collect your thoughts together. It is hard to do at first but you will get the hang of it.

Next I mock up some very VERY basic screens in a test project so I can work out what needs to go where. I tend to "print" everything to onenote 07 as I can organize better using it.

by the time I have some sample screens I tend to have a better picture of how the application will function and will start to create conceptual objects. These are basically little squares with responsibility and dependency information in them.

by now I have a list of objects and what they do so I do out a table in the order each needs to be completed or if two need to be completed in tandem. This gives me a structure to work off.

I use the above structure to create class files in a solution. Each file is then populated with pseudo code. This section is very important as things like object incompatibility or merging tends to take place.

I refine each object further in pseudo code. The start as a comment paragraph, then into step by step instructions. At this point coding will be trivial in a sense. Sure there will be code that you need to implement that you have never used before but at least you know what this code should achieve. I never remove to steps though as I tend to use them as comments.

Obviously I have glossed over this a bit so do understand that there is a lot of refinement involved but it tends to be much easier to change a line of text then a line of code and by the time your pseudo code actually looks like code 90% of your refinement will have routed out silly errors and "where do I go next" issues.