Haha, good luck, usually the project is "agile" and experimenting and pivoting and "we'll know it when we see it" and only 7% of people are actually clicking a button so let's redesign those screens and so on.

You still need somewhere to start, though.

My experience is absolutely opposite.

Often, coders receive a design of Database from leaders, with SQL store procedures.

Only then they will follow the mock-up and then start to code.

So much goodness comes from a well designed database as you point out, but I agree with barbecue_sauce too. Do the interface mock-up first (and get the customers agreement), then do the database design and then build everything in between. The mock-up gives you a functional insight (an understanding of the problem domain) that's crucial to designing the database. Technical debt is heavily weighted to the database. Get the database design wrong and you'll be paying for years. As whycombinater says: > The bottom layer, designed inconsistently, will percolate through That's why it's so useful to get a front-end mock-up done. It's a learning exercise that's key to getting the database design right.

I know it. But you have to pay the cost. Do the mock-up, build an MVP just to get the insight from UX viewpoint.

My point of view is that, it's not worth the trade-off here (especially you have only limited time-budget or dev-budget).