Design from the database first through to UI or t'other way round?

Question

Do you always lean towards thinking of db schema when starting or planning a new project it or do you go the other way and start designing UI then moving down the stack?

Or do you have a different way of developing?

Not really an agile/waterfall/specs/stories question just a way of getting a handle on which way people lean when working on projects personal/professional or otherwise.

I have decided that both are the best ways in the past and am currently in the UI first camp but that can and will change!

Cheers John

Answer 1

Lay out your screens first that way you know what you need in the database.

If you start with the database then you are usually starting with a set of assumptions about how the application will function.

Answer 2

I tend to start in the middle and work out what the app will do and how, then bounce between the UI and the database design as they can inform each other.

Answer 3

This seems to be very situational. With the work I do, most work starts at the database, because the databases I work on are enterprise resources - they are used by multiple UIs. It would be detrimental to have the DB designed around the vagaries of a specific UI that will likely change often.

On the other hand, there are situations where it might be more beneficial to focus on the UI, and let the database design come later - perhaps in an embedded DB mobile app, for instance.

Answer 4

Generally, I start with the database first and build the UI to suit it. There's usually some back-and-forth though as I may need to change the database to suit the requirements of the UI or vice-versa.

This route, starting with the database first, is how I was taught in school and it stuck with me.

One programmer that I worked with would start with the output. He'd start by figuring out what needed to be done (i.e., what reports need to come out, etc), then work on what data was required to get there. The UI and database were built at the same time.

Answer 5

In the projects I work on, I find that the UI is where a lot of my requirements come from -- it's the part that the end-user cares about (or at least thinks about).

Answer 6

Essentially, I find out what the functionality is supposed to be first. I don't deal with UI or how it looks or how it's supposed to be input, I deal with what the user wants to do.

I then build a data model around that. Sometimes it's a very simple data model (especially if it's a simple requirement like "play a movie"), other times it's very complex.

Only after that's been decided upon do I try to design a UI that reflects both the model and how the user expects input to work.

Take that for what you will; it works for me fairly effectively.

Answer 7

I do both. I typically draw out a prototype of what the screen will look like and then try to develop a data model from that. Instead of going directly to a database I find that this works a lot better as with my UI I can see the need for properties (or fields in a db) that I wouldn't have thought of otherwise. From there I then develop the model and bounce back and forth till the both suit the needs of the requirement and then I worry about database schemas. Typically though the model itself will define the schema for me so that's taken care of.

Answer 8

above all else, concentrate first on ensuring that the system will solve the problem that it is intended to solve.

gather requirements to define the workflow, data, user interaction intricacies etc, then build out from there.

of course you will always have to tweak things here and there, but from my exerience i find that people who subscribe to one philosophy or another (i.e. always start from the db and build up vs. ui and dive down) many times will end up with a solution that does not fit the problem.

Answer 9

Model the domain first - that will tell you how to build your DB. Find your requirements next - what do the users need to do with the application? That will tell you what functionality needs to exist. With that in hand, you can create your DB schema and your software model (whether it's OO, or functional, or whatever, you'll have the necessary information). THEN make a pretty UI that exposes the functionality you built - of course, the UI build can be done in sync with the functionality as well, but both should come after determining what the domain looks like.

Answer 10

I just recently stopped designing my data model first. I worked with a developer that got me turned on to Domain Driven Design. I now sit through and design my Domain model first, and then my data model. at the same time I take into consideration any challenges the UI might present.

Answer 11

To the average user, the UI _**IS**_ the software. They don't care about how data is stored, what platform you use, etc. So if your software will be used by people, I strongly recommend starting with a UI- either a prototype or mock ups. Show that to the users and get feedback. Then build up the business layer and data layer.

I find this helps gather requirements. Non-technical users are much more likely to tell you "oh wait, we need another field on this page" than "we need another attribute in this table schema". They may also say "we need another button here", which usually translates to some additional business logic, etc.