When i proceed to develop a software, ui design or database design, which should be first?

Question

I tried to design the ui with some ui mocking software, but i found it's hard for me to settle down all the detail of the design, since the database didn't design yet.

But if i first design software, then the same problem occur, I didn't have the UI, how can I create a prominent UI ?

Hinrichs

This is known technically as 'a Chicken and Egg' situation. – Oxbow

Answer 1

UI first.

Mock up an elegant and easy-to-use user interface (and workflow) thinking from the point of view of the user, and only then think about the underlying database / data structures you'll need to bring that UI to life.

If you can't design your UI because you haven't yet designed your database, you're doing it wrong IMHO. How many annoying pieces of software have you used that suffered from letting the database design drive the UI design?

Edit: As others have pointed out, you need to start with use cases / user stories. The UI design and database design, whichever order you do them, should only happen after you know what your software is trying to do, and for whom.

Edit by Bryan Oakley:

_{(source: gapingvoid.com)}

Multimillionaire

I won't downvote because it's otherwise a good answer, but database shouldn't be driven by the UI. The database is its own entity and deserves its own engineering effort. The result of creating the database based off of the UI is that it doesn't scale well performance-wise, and it isn't easy to maintain. – Ingvar

I wasn't implying that you should structure your database to match the structure of your UI - that would be the same problem going in the opposite direction! – Multimillionaire

Downvoting because I have seen this gone wrong innumerable times through my career. If you start with the UI, you will often end up designing something that doesn’t make sense and can’t be realized in practice at all. “User Interface” literally means the interface that enables the user to control your system - so you’re saying, design for that system before defining what that system is or does, and you’re going to fail. Classic systems design begins with defining a domain model according to user requirements (who and what) and then designing suitable UI for that - not the other way around. – Baba

@Baba than you haven't seen a lot of systems. Or maybe you worked on systems that are just used to manipulate data in some corporate environment. Workflow (i.e. use case is primary, then it comes UI and then and only then you can create model and DB) – Veg

Answer 2

Put the user at the place he deserves. Design UI first.

Database is only a consequence of user needs.

Mceachern

Answer 3

use cases first, neither ui nor database.

Espadrille

That's true enough, though one could argue that developing use cases is merely the first step in designing the user interface (where "user interface" isn't necessarily synonymous with "GUI"). – Gnu

Answer 4

If you're trying to solve a problem in an object-oriented language, it's recommended that you start thinking about the objects involved. Don't worry about the database or the UI until you've got a solid domain model nailed down that addresses all the use cases.

You don't worry about the database or the UI at first. You can serialize objects to the file system if you need persistence and don't have a database. Being able to drive your app with a command line UI is a good exercise for guaranteeing that you have a good MVC separation.

Start with the objects.

UPDATE:

The one advantage that this approach has is that it doesn't prejudice the UI with a particular database design or vice versa. The object are agnostic about the other two layers. You aren't required to have a UI or relational database at all. You're just getting the objects right. Once you have that, you can create any UI or persistence scheme you like, confident that the domain model can handle the problem you've been asked to solve.

Whistler

Best answer yet. His problem doesn't lie in technology issues, it lies in design issues. UI should not need a DB to run. DB should not need UI to run. If he needs to make an interface between the two, that's cool, but they shouldn't rely on each other now. – Ingvar

Don't worry about the database or the UI until you've got a solid domain model nailed down that addresses all the use cases. What is a domain model == class diagram ? Use cases means in which situation user will use this software, right ? – Hinrichs

Use cases describe how users what users will want to accomplish with your software, but it doesn't necessarily mean that they're use a GUI to do it. I can design a batch process that will still use that object model. I can persist objects in lots of ways, not all of them relational. – Whistler

... but the batch process is a user interface. Just because he said "UI" doesn't mean "GUI". Decide how the user will interact with the system first, choose the technology to implement the system second. Software development should always begin with meeting the needs of the user, and users don't care about object systems and databases. – Gnu

Fair enough, Bryan. Of course you have to think about inputs and outputs, because a closed system isn't very useful. I still think it's useful to think about what you're trying to accomplish first without having to spell out what form that input and output will take. – Whistler

The CLI is, of course, an interface. However, it takes very little effort to design and can be considered throw-away code. The idea is that you don't put permanent-design effort into it when you don't have your design nailed down. – Ingvar

Answer 5

All the above answers address your issue in a right direction. That said, I would follow the SDLC thoroughly. It helps you understand the need for the solution for the problem at hand. Then comes the requirement gathering followed by the design either UI / underlying structure that supports the UI. It's a procedure but you would benefit in the end.

Loony

Answer 6

Your question is very subjective.

My opinion (and it is just that) is that database and underlying structure should come first. It can often help to put down the keyboard and mouse and compile some notes on paper.

Lay out goals like what you want your application to do, list the features you require and then start thinking about how you'll build it.

This method works for me in application design.

Camargo

I agree with the "Lay out goals" statement but disagree with the notion that meeting the goals of the user starts with database design. Users rarely ever care about databases (the exception being, when your users are database designers). – Gnu

Bryan, users care passionately about badly designed databases because they are slow and affect them every second of every day. Just because they don't know the problem is the database design, doesn't mean it isn't more important to them than how the UI works. – Pummel

I agree users care passionately about performance. I don't see how that can be construed as them caring about database design. Ask any user "should I make the system faster by improving the database design or by doing something else" they will either say "I really don't care" or "what's a database?". I'll stand by my statement that users don't care about database design. They care about getting their job done. If that means every database call gets routed to elves who put envelopes in slots, as long as its performant they don't care. – Gnu

Answer 7

usually you need to manipulate some data in the solutions you develop. So you should consider how this data is organised first, stabilizing this layer is fundamental at the beginning. I agree with duffymo's comment about designing the business objects first if you are in a OO world. Mapping these objects to the DB will be a part of your work. Then you add business functionality and work on the presentation layer. Of course you will have to do some refactoring from time to time, but usually the refactoring impacts the business and presentation layers more than the database.

read this, it is a good technique. DDD - Domain Driver Design

Stark

Answer 8

Would you build a house without a foundation? Database design isn't the fun part but it is the foundation of most business apps and if you get it wrong it becomes the most costly to fix and the most costly to maintain.

That said, I note that there is no reason you can't work on both together as they intertwine. But before you can do either, you need to understand the requirements and the business you are writing the app for.

Pummel