There are many books on the "right" way to design. They're usually geared towards larger projects so they may not be appropriate for ALL projects, especially smaller, single form type of applications.
If you're developing for a client, it's good to start with a screenshot so that you can discuss what will have to be included. It's not important to have the layout exactly right and there's usually NO code. It's just a point of reference when building up a functional spec, which includes exactly what the program (or a form, or even just a tab on a form) will do, will show, will save or not save, etc. From that spec you can write your objects, or at least start designing them from a high level. After that, you can go in start writing code. We usually have a junior level programmer do the GUI since it's mostly renaming controls, adding events, etc. The more senior developers code the components, web services, DataSet schemas, etc. When the junior's get done, the seniors do code reviews to make sure the juniors didn't do anything crazy
On smaller projects, I still start with a basic GUI. I may or may not rename controls in the beginning. I hate spending 20 minutes renaming them and then deleting half or moving them around or whatever - I hate that rework. Once I have the screenshot close to what I want, then I can stub out code. For me, that means creating functions (minus any code) with comments to let me know what each function will do. Each is marked with "// TODO" which in C# shows up in the Task List, so that I can easily go back and put all the code in.
-Nerseus