Plan back-end logic
Emphasis here is on planning: put together diagrams, plan the classes that are needed, define relationships, and try to predict where complications might come in. This is a good step in which to identify potential trouble areas early, and thus adapt your solution before going any further. An example of this sort of complication might be the communication method used between classes when neither class is meant to know about or control the other (a problem that I often use continuation passing to get around).
Plan the UI
This step is pretty self explanatory - just draw up some sketches of the UI. It might not sound like it belongs at such an early stage, but by planning what you show the user you figure out what inputs will be required, as well as what sort of protection levels to include, if something doesn't add up here you can go back to step 1 and revise the back-end plan.
Share your design (optional)
I only show my designs (either the logic or the UI) when the program is meant for selling later, which is why I've marked this step as optional. Show your design to a friend to get their opinion on back-end architecture (if possible), usability and layout. At this stage your design might make sense to you, but that doesn't mean others will understand it - in fact, other people often find 'amateur' layouts to be highly confusing. When I say amateur here I mean that the UI was not designed by a professional artist/usability engineer, and the back-end architecture (probably) wasn't created by someone with a job title like Software Architect (a very senior position where I work).
Implement back-end logic
Only now are you going to begin to write any code. Begin with the most core sections of the design, and work outward. For example, if you were creating a board game program, you would probably create the Player class before the Board class (as the Board class would contain and track Player instances).
If during this implementation something doesn't fit, or something seems to be missing, loop all the way back to step 1 and ensure that the changes required to fix the issue won't introduce problems later.
Test as you go
This is not a step on it's own, and should in fact be used throughout all implementation stages. After each testable feature of the back-end logic is created, test it in isolation - this includes writing auto-test cases when possible but also regular manual testing. I've had far too many students try and implement whole projects from start to finish without doing any testing in-between: it always ends in the debug process being much longer and more error prone than it needs to be.
Ideally you want to create test cases as you go, so that if a later change affects something you've already made it will be automatically detected by the test-cases.
Implement and link the UI
Not quite the last step, but definitely the most satisfying, once the back-end logic is working correctly it is time to implement the UI and link it to you logic. Add one component to the UI at a time, link it up the matching back-end logic, test it, and repeat until everything is hooked up.
For an event driven GUI program this step is often pretty trivial, however for a program driven by a game loop (or one where elements are re-drawn on a canvas repeatedly) this stage might have to be done it parallel with the creation of the back-end logic as it can be hard to tell if the logical state is correct without visualising it.
Once everything is hooked up you need to do more testing, quality is key to good reviews, which are in turn key to further sales. Test the program as a whole for yourself. Get someone else to test it too: for functionality, bugs, and usability.
This whole process is iterative: if you find a flaw at any stage of development (no matter how small), you should go back as far as necessary to remedy said flaw. This can be a bit annoying, but it does mean that everything is always being built on the strongest foundation possible. You might even iterate all the way back to stage 1 once you've reached the end if you think an important feature is missing or not up to standard.
Your done. Congratulations!
Sadly that's the easy part, now you need to market the product and start to make sales.