The practice of "outside-in" test-driven development recommends coding the UI first, driven by tests in which you stub out the back end. You continue working down the layers of your application like this, testing (and coding) each layer of the onion until you are ready to move inwards; the model is typically the last thing you write.
This has advantages and disadvantages. Having a working UI prototype you can show customers means you can iterate the design of your UI quickly without getting bogged down in the data model. It also helps you keep your UI decoupled from the model, and it feels encouraging to have a visible working UI early on in the development process.
On the other hand, the UI is typically much harder to test than the model. It requires discipline to remember to test your model code at a lower level, and not rely on fragile acceptance tests for all your testing.
I'd recommend a balanced approach, switching between outside-in and inside-out styles as is appropriate for the situation at hand.