When do you design the GUI first and the backend code later, or vice versa?

Question

When I'm working on a project, sometimes I'll design the GUI first and then write the backend code to make it work, but other times I'll do the opposite and make the GUI once I have the system working. How do you choose which way round to code and are there any particular types of project or circumstances that would lean you either way?

Answer 1

You need to create something which would let your testers start immediately. Try to think from that prospective.

If they are working on manual UI testing give them a shell of UI with stubs for all the functionality. If there is an interface to be tested make sure it works (even if it returns dummy data) so they could start working with it, etc.

Most of the time it's the UI. You could show it to your users and get immediate feedback which is really useful.

Answer 2

I think writing the GUI first and showing a quick prototype to the end-user helps both to share the same vision of the final product. IMHO, I consider server-side code as not dependant on GUI code.

Answer 3

I often prefer to start with the backend code when the project is "data intensive" (create, read, update and delete elements, show lists of data).

GUI first when developing quick prototypes.

Answer 4

I would assume that this depends on the type of project, and yes, i am aware that is not really an answer as they all do. But usually you can visualise how the front end wants to look from the back end aswell.

I would always have an eye on the front end myself, as at the end of the day that is the part that wil be visible. Also, it usually helps get an idea of what is expected by visualising, even if in block form or via post it notes what you want to see as to what it is you are indeed coding.

Of course, it always helps if it is for a client and they give you the visuals before hand :) That way as long as you match the visuals you can still go to town with non visual related back end fun.

Answer 5

They really go hand-to-hand. You can't design your UI without having at least basic design of the back end for the features that UI will cover. And a new back-end feature is added, part of the design is to figure out how that feature is exposed to the user and how it fits in the existing workflow.

Btw, I really don't like the quick and dirty UI "just to give the testers access to the feature". Once you build the UI, you will rarely have the time later in the project to rebuild it from scratch (assuming it's a project on a schedule :-)). If you are building an UI, build it pixel perfect, the way you would like it to look when shipped to the customer.

Otherwise you end up with something like this monstrosity. :-)

Btw, if you need to build UI prototype for usability testing, make sure it's built with something that cannot be integrated in the production code. For example, build the prototype in Flash if you are writing C++/C#/Java code.

Answer 6

Neither, nor. We usually split up the project into tasks. Some tasks are part of building the requested UI and some are part of implementing the necessary functionality behind it. Different people work on different tasks, thus part of the team is doing the UI and another part is implementing functionality behind it. So we work in parallel on both, UI and functionality.

It's only important to get the tasks into the right order. It's useless if we have functionality ready, but the UI to use it will take another two weeks. It's also useless to have the UI for something ready, but it won't be functional for another two weeks, as the backend functionality is missing.

That's why we try to specify small milestones. Nobody starts working on another milestone till all his tasks of the current one are finished. A milestone always groups frontend and backend functionality together. So if a milestone has been reached, the frontend for every implemented functionality must be ready and every implemented backend functionality must have a frontend to test it.

However, in some sense you can say we do first backend code and then UI, since when saying a milestone needs to offer UI to test functionality, it doesn't mean that this is the final UI we will ship. Usually near the end, when almost all backend functionality is ready and tested, we often do a UI overhaul. This is because UI for testing needs to be ready for a milestone, but it may not always be nice looking or the UI we will finally ship. Often the UI would slow down the whole project (our apps usually are very UI intensive, since we don't like to produce apps with boring standard UIs, we want lovely looking UIs that make you say "Wow, that looks awesome!"), thus we often need to implement an intermediate UI to have a UI ready for the milestone and for testing. More often than less we then revamp the UI as final step before release. As we already have UI for everything, it's no big deal if we can't revamp some parts of it (because of time constrains), after all, there is a UI, it's just not beautiful, but it's working and tested. So we will try to revamp as much as possible within the given time frame, knowing all the time that if we must stop the revamp process tomorrow, we have a fully working, shipable application. The UI revamp is just polishing, IOW it's nice to have, but you could also release without it.

Answer 7

There are two questions to ask to determine this: a) which one is most important b) which one is hardest.

If you are writing an order processing application then clearly it's success is going to depend more on the user interface than the backend code. So you should probably design that first, get some level of approval for it from your customers, and then design the backend to fit in with it.

It should also be said that the design isn't finished until both are designed, and whichever you do second may involve redesigning whichever you do first.