Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
When you build an application, is it better to design the UI first (in Photoshop or whatever), then implement the functionality following the UI you just designed, or do the programming and build the design as you go?
Advantages I see using UI as reference:
Disadvantages:
any others? :D
I only see advantages on doing the UI first:
You don't even have to use Photoshop or anything fancy (or expensive) to design your UI first. You could use this very nice (and non-expensive) tool called Balsamiq. It allows you to build very clean mockups that allows you to focus on functionality rather than fancy stuff which is very important at an early stage.
I've been through pretty much every scenario that I just listed and designing the UI first has been a very good decision for me in several projects.
The only drawback I'd say is that it takes more time upfront. But that's not even a valid argument against it since you'll definitely save more time later based on everything I just listed.
If you have any customer engagement whatsoever, work the UI first, show it to them, change it a few times (from what they asked for to what they really want), then write the back-end. This saves you the time of writing, and then rewriting, and then rewriting again, the entire stack.
If you don't have that customer engagement, it really doesn't make much difference in my experience.
I should mention though that I am not recommending writing the entire UI before writing the back end. Everything should be done one behaviour at a time, so that there is always a working application to demonstrate, even if it lacks a lot of expected behaviour.
I've found you often need to do both in parallel. for example, the UI might dictate that you need a web API for AJAX interaction, or a certain structure for pages. on the other hand, you will need to design how your lower tier will access data and provide services. then the fun part is creating the controllers to wire them all up.
It really depends on the kind of application you are going to develop. But let's assume you are going to create a rather complex UI with lots of functionality, then having a clear concept first, written down on a piece of paper or as a sketch in some kind of drawing program, will help you to get it right.
That does not mean you should implement that UI as a whole before starting to implement functionalites at a time. Better implement only as much of it as you need to make a certain functionality work (scrum people would perhaps call it a "user story"). Use your "Photoshop UI" as a rough guide or "vision" how the final UI will look like in the end, but not more.
Disadvantages: the programming will get more complicated, so development time increases
What makes you think that? Following no plan will make things more complicated, especially on the long term, that is my experience.
You should generally design around functionality.
The reasoning behind this is that your customer will have an idea for a system in mind, and yet they won't really have all of the details worked out. These are things you will need to tease out over time, and they are things that could - and most likely will - change. When you start with the GUI, you are asking the customer to put all of their ideas onscreen, and yet you've missed the opportunity to get an unbiased view of the processes and functionality that the customer needs. Sure, they might have many of their needs defined with how they might like a screen to look, but without understanding critical workflow and data management issues, you only get a small part of the picture up front. GUI's can be finicky things to get right, and you can find yourself spending a lot of time on them, which may risk running out of time to do the serious back-end stuff, and by relying on the GUI to dictate the overall design, you risk creating a dependency between the UI and the back-end.
Starting the other way around seems less intuitive to many people (including the customer), but it can save you a great deal of heart-ache later on. While on the one hand you want ot put of major decisions until the last possible moment, having as much information as possible up front will allow you a little flexibility in how you go about implementing a system. You'll need to know early on whether you will be handling large volumes of data, and whether you will be communicating that data beyond the confines of the user's local PC. Will you need a distributed system, N-Tier, Web-Based, etc? Knowing this stuff up front gives you time to research your options while you are encoding your business rules in libraries that could exist in nearly any configuration.
Something else to ponder, is that you may wish to deliver a whole system at the end, or schedule major milestone releases, or release incrementally in the Agile style. When you begin with the GUI, you lock your customer into a particular mode of thinking, that is, in how the software will be perceived. If you start with the back-end and release incrementally, you can build a rudimentary interface and tell your customer that it is simply to provide a means to conduct a controlled test of functionally, so that the customer can decide how best to present that functionality to their users, maintain their branding, and so on. Starting with the GUI will kind of limit everybody's thinking in terms of presentation possibilities to be biased towards whatever everybody sees first.
Disadvantages:
the programming will get more complicated, so development time increases
There's no reason why this has to be true.
If you are developing an application of a line of business type, then you must tailor your application to the business flow required for each business function. There are certain GUI aspects of the application that won't be affected much by the specific functions of the application such as logon, help, backgrounds, menu styles, footers, etc. You can build the common parts in a prototype and add your functionality to that or demonstrate the functionality using BPM first, then merge it in your prototype if necessary.
Try to seperate design from functionality, where possible and have a communication layer between the two.
This way you can have a dumb ui and a smart backend and development of both is rather independent, giving you best of both worlds.
Generally, you want to work with the users, in order to make sure you're building something they will find useful. This is the best way to build applications that support the users' existing workflow.
On the other hand, simply supporting existing workflows may miss an opportunity to build a category-breaking killer app: computer support can sometimes enable an entirely different workflow. This is a higher-risk option (if it is available at all), but it may occasionally pay off big.
As far as functionality is concerned: after thoroughly understanding the users' requirements, you need to make sure the core functionality actually does what they need. Then (ideally) you should make sure the UI properly reflects this core functionality, so that a user can understand what actions he is performing. Doing this while also supporting workflows as mentioned above (whether traditional or novel) can be nontrivial.
In any case, start with your users. The more you understand the user's needs, the more likely you will be to produce usable software.
I'm a web UI dev and I actually think, unless it's a very basic throw-away one-off content site with a minimum of specialized behavior, that creating and approving a mockup with the intent to build an exact duplicate without having touched any of the underlying back-end/model-controller/data, or whatever concerns you're throwing under somewhat general term of "functionality" is the worst way to go.
There are three reasons for this.
It is all too easy for clients and just as easy for project managers and bosses and execs and yes, devs too, to get way over-invested in the UI and forget about the problems the app was supposed to solve in the first place.
Nobody is going to foresee all problems/challenges inherent in the general app scope right off the bat. When you have a very specific UI expectation set, you may be in for a lot of unnecessary work due to complications if you're dealing with inflexible corporate types who know more about dots on Is and crosses on Ts then they do actually solving problems when a simple non-UX-impacting change could have meant the difference between days and weeks.
You could be missing major opportunities to find a better way of doing things that simply don't avail themselves without something to actually get your hands on and play with. When do we decide what is good and bad UI or what might be better? When we're using apps, not when our noses are in Photoshop.
If you are in the blessed position of having some control over the dev process, do a bit of planning and then knock out that first prototype in its crudest most basic form possible ASAP. Sure comboBoxes are nice but a select box will do. Modals with ajaxed content are neat-o but reloading the page isn't going to kill anybody on the first run. Just get the problem solved first. THEN start fussing with the UI.
Read up on concepts like MVC. If you're familiar with the client-side separation of concerns on the web, the concept won't be that totally foreign to you. Then separate concerns as you see fit (but don't sweat dogmatic application of any pattern - that's missing the point). At the end of the day, UI should be nothing more than a mask that you fit onto an underlying app that already gives you a means of accessing the data and communication methods you need but when you start with the UI with no underlying plan or full understanding of the problem, it's easy to get concerns twisted. Get your data and communication problems solved first with basic, ugly UI. Then get fancy.
Functionality is not the same as UI except for some very trivial applications.
Functions, such as:-
Cannot be expressed in a UI.
Furthermore a good UI is as much about the sequence an flow of events as it is about appearance and layout. Use Use Cases to capture the essence of the users interaction before you start in on designing any screens.
So you are on the right lines. But try to get a list of functions, and, a set of use cases before you start on the UI design. You will be surprised how much this approach can simplify your design.
