From a startup perspective I strongly disagree, I think the UI should almost always be designed first. The HTML/CSS/JS frontend that the users see comes first, and have it hooked up to an empty backend that does nothing. Then once the UI requirements are fleshed out and the final specs nailed down, only then the database schema should be designed. The backend glue e.g. Django/Rails comes last.
I find this approach has led to the fewest number of code rewrites and database migrations needed to get from initial mockup to finished product, because UI requirements can change much faster and are more fickle than DB schemas and backend code.
I agree that the UI / user experience needs to be spec-ed out first. However, in terms of actual development, writing the DB schema's first is usually the right call. I typically feel that things should be designed outside-in, and developed inside out. Of course those are just general principles.
This is brilliant, totally stealing this. Reading the other threads found myself agreeing with both "design UI first" and "design DB first" and couldn't reconcile the two. But if you split it into design and develop it makes total sense.
I totally agree with this. On my experience that is the approach that works best.
1 - Define the requirements
2 - Design the UI AND its behavior
From seeing the UI and understanding how it is expected to behave you can get a clear idea of what entities and attributes you will need, from there you can derive the database design.
3 - Design the database in a way it fits all the data you need to display on the UI, and all the data you don't need to display but need to make the UI behave in the way you need it.
4 - Code the business logic required to link the database to the UI, in whatever language you choose.
Schema design and UI design should both be done at the beginning and designed _concurrently_. UI requirements can inform schema design. But there's always going to be an impedance mismatch between the two: schema design optimizes for performant storage and retrieval of data - it's data that has been optimized for machines. UI design optimizes a users ability to conceptualize and use data - it's data that has been optimized for people. Code is the glue that helps mediate between these domains.
I have consistently found that this approach leads to data structures that are insane to deal with in any kind of scalable, performant way, unless the front-end developers are disciplined and reasonably knowledgeable of how algorithms and databases work. Mileage may vary.
I agree. I'm a relatively junior developer (<2 years) and was told to create a proof-of-concept UI before the web api or db were designed. When the team eventually moved to build the supporting service and db, so many headaches ensued as certain data contract decisions that made sense for the UI don't necessarily work as-is for the service/db. Learned this the hard way
I find this approach has led to the fewest number of code rewrites and database migrations needed to get from initial mockup to finished product, because UI requirements can change much faster and are more fickle than DB schemas and backend code.