Some devs architect their designs in UML completely before starting any coding, and others just jump right in. I've seen good designs both ways. The key is, I think, to be open to redesign and refactoring at any stage of development. A beautifully-architected design, conceived in a 300-page requirements document and drawn out with a stack of state and sequence diagrams, can be utter garbage when coded.
Be willing to throw out your work whenever necessary. Have the tests in place to prove that your refactored design works as correctly after changes as before. Having tests that you trust will give you the courage to change.
The best definition I've come across so far for architecture goes something like this: When you learn how to read the time off a clock you've basically learned about its architecture. That there will be at least two needles -- a fat and short one denoting the hour and another thinner and longer denoting the minutes -- moving in a certain direction.
Design on the other hand is about how the clock actually looks and feels. Does it have all twelve hours etched on? Does it run on quartz or do you have to wind it everyday? Is it 10' tall or is it a wrist watch?
Implementation is about making the parts that make the design tick (pun unintended) that is the design sticks to the fundamental rules that our architecture laid down.
On the more practical side of things there are things called architectural patterns that significantly reduce the amount of effort you need to invest on defining an architecture when you start writing a brand new application.
Sometimes a prototype can be a really good way of finding out some possible ways of doing it wrong. Don't get attached to the prototype, don't worry about details unless it is a detail that will effect the overall system, just use it to understand the problem. Once you've had a good look at the problem you can either start a new prototype or if you think your basic design is right you can start a more detailed design process.
I think you should start to write code as soon as you have a clear view of how it will eventually be written, be it after 10 minutes of thought or after 10 days.
In order to achieve that you should use every tool at your disposal according to it's goal - I find mock-ups to be extremely helpful when I need to understand the reqs., database diagrams for designing the DB structure, and class diagrams for code (although that part I sometimes skip :-)).