A very common practice in our industry is to first build the UI and tie in the back-end thereafter. The argument, for the most part, has been that the end-user gets more involved from the start with this approach and thus it gives us confidence that we are indeed building the right product. One major downfall I've realized with this approach is that we tend to end-up with a poor domain layer or lack of it for that matter. Since we are so focused on feeding data into our shiny UI. Here is a quick example to illustrate my point. Decouple the UI and the data layer from your application and see how much can be reasoned about with what's left. In other words, when all the bells and whistles are stripped off, what do you have left? How rich is your domain or what's your domain for that matter? What is your application about and how apparent is that in your code?
Ok, so maybe you can make a point that there is such a thing as a two-layered application and that not everything needs to be domain driven. Point taken. The most compelling reason I've seen for thriving toward a rich domain is that it's easy to test and reason about your application. I find it extremely helpful to think of my application as serving use cases rather than serving data. Huge difference. And what a better place to exercise your use cases than through a rich domain.
So what's a rich domain? I think of it as a layer that speaks my business domain and expresses allowed use cases. How rich it is, depends on how versed it is. Therefore, next time you find yourself designing user interfaces prior to expressing use cases to be served, my suggestion is to start from the latter and walk your way up. Let your UI plug into your domain.