So you are always starting your developments first by writing the user interface ? I would say that this way of doing is generally associated with "prototype" development in professional environments, but then again not necessarily. In small companies writing "small" applications and starting with the UI happens very often (also it happens even more often that the "small" application you started grows and grows and grows and becomes a monster application requiring refactoring, additional developers... but I digress)
So it is not necessarily a bad idea, it depends on the size/complexity of the application that is being written and you said it yourself you are writing these programs for yourself. Psychologically, having an UI may also help in that you see your advancements and that gives you motivation. Whereas if you are writing your code-behind and test cases first it may take a dew days before you really start to dwelling into the UI... Unless your mind accepts that test cases are achievements too :)
However, as you said it yourself, doing the UI first without thinking about the backbone of the application will lead you into trouble. It is very tempting to start the "fun" part (I am like you, I like having neat interfaces). But, before that, and even for small programs, just stop for a moment, take a piece of paper and draw some diagrams about how your application works. How your components will reacts to UI events. What are the business (or game!) rules to implement. Prepare a quick to-do list of things to implement and prioritize them by what you think is critical. Also, when programming, resist the urge to implement not critical features/options that will inevitably come to your mind, note them down and take a look at them after cooling down.
You should strive to achieve maximum separation of UI and business/game logic. Ideally, your game code should work whether you have a command-line game (for example: "play e2e4"), a simple 2d UI, or a full-fledged 3d UI driven by the latest version of DirectX. Complete separation is not an easy job and it is where knowledge of Object-Oriented and event-driven programming will be most useful.
Now, the good thing is that you both love programming and writing programs, and you are just a little over-enthusiastic... No scratch that. You are enthusiastic and that is a good thing.
On the refactoring subject, you may not feel the need for it, but maybe it is because you know that your code is a mess and that it would take forever to change things. However, if you organize your ideas a little bit before starting, you should have less code to refactor (but there will (should?) always be a little voice in your head that says "this could work better if..."). Check out other questions on this website on the subject of refactoring, other people have covered much better than I could do it.
Finally, if you feel you are not writing proper OO code take a look some books you could read in order to improve on that, for example: https://stackoverflow.com/questions/1711/what-is-the-single-most-influential-book-every-programmer-should-read