Well, I think everyone is different as is every project. But here is what I personally do...
For my own projects, i.e. no client requirements, I start at one end or the other, either with the database structure or the UI. I then work down through the layers making sure that I maintain clear separation of concerns to make testing (unit and system) as well as maintenance as easy as possible.
One thing to note is that regardless of your approach I think the process is iterative. I will often work, refactor, work, refactor etc so don't get too bogged down with the details and feel you have to stick to them. The requirements are the key thing (whether for yourself or for a client), the technical implementation is largely irrespective.
When dealing with clients the process is somewhat different. You will need to do a fair amount of design up front so again think from one layer to the next trying to keep as much of the logic in the correct layers as possible. As an example you have your DB, then you want a data access layer (DAL) to abstract your code from the DB access. Then you want specific business logic libraries which use the DAL, this abstracts the higher portions of code from the data (they go through the business layer) etc etc.
Just think of each level and try and keep it as generic as possible, that way when you wish to change the storage for the data, you simply change the DAL and everything else works as before...