Generally speaking, is it better to make all the functional parts or get UI working first - or a mix of the two?

Assuming you're working on something large, is it generally accepted practice to get all the functional data harvesting blobs working before any UI, get all the UI working one piece at a time as you go, or something in the middle?

We all know to break work down in to manageable pieces, but the question is ultimately whether UI is included in manageable pieces I suppose.

For the case of the example, consider a GUI application with one root window, but over a dozen tabs in various docks to separate different data components. Each individual tab has a relatively complex set of moving parts behind it from a functional units perspective.

The example application in this particular question is here with the accompanying blog and the original commercial product.


9 Answers 9


There is a general conception amongst many business users and clients that when it looks complete, it is almost complete. As you likely know, this is far from the truth. One can have it looking nice, but with no backend and some users think that making it look nice is 80% of the work, not 20% (or the other 80%).

Countless developers can tell horror stories of this - getting a mockup of the pages done in Microsoft Word using screen shots of some other tool, and the client saying "so, you've almost got it done?"

You need to pace it so that all parts are done when its done. Trying to do all the backend first and then all the front end will lead to the end user thinking you're not doing anything and asking why you are getting paid when there is nothing to show for it. On the other hand, front end first and you'll find the end user making niggling changes and consuming all our time.

The worst case with a 'one first and the the other' is when you get to the other part, you find that it doesn't fit the design at all.

Thus, build both. Show progress in the front end, make the back end work with what you are building. In many cases its a good idea to deliver incremental builds and make sure you're making what the client wants (this gets into Agile). Going too long with out 'visible advances' can hurt the client relationship (this is for both cases of 'everything looks done early' and 'nothing is done until the very end' - its hard for the client to see the framework being written or the unit tests or data sanitization as progress).

Joel wrote about this in The Iceberg Secret, Revealed:

Important Corollary Two. If you show a nonprogrammer a screen which has a user interface which is 100% beautiful, they will think the program is almost done.

People who aren't programmers are just looking at the screen and seeing some pixels. And if the pixels look like they make up a program which does something, they think "oh, gosh, how much harder could it be to make it actually work?"

The big risk here is that if you mock up the UI first, presumably so you can get some conversations going with the customer, then everybody's going to think you're almost done. And then when you spend the next year working "under the covers," so to speak, nobody will really see what you're doing and they'll think it's nothing.

This is again reiterated in the blog post Don't make the Demo look Done which has this helpful graph:

How done it is to what it looks like

Note here the two options generally reflect the 'get the ui done' (and then the expectation is that you'll be done soon) and 'get the backend done' (and then the customer is worried about you missing the deadline).

How 'done' something looks should match how 'done' something is.

Every software developer has experienced this many times in their career. But desktop publishing tools lead to the same headache for tech writers--if you show someone a rough draft that's perfectly fonted and formatted, they see it as more done than you'd like. We need a match between where we are and where others perceive we are.

This article also brings up an important point about the type of feedback you get with different levels of doneness of the user interface. If you have something that looks complete, you're more likely to get feedback about "could you change the font" than "this layout doesn't work - there are too many tabs."

For those who are fighting with this in the Java Swing world, there's a look and feel called Napkin which makes it so that the UI doesn't look complete (even if it is).

The key here is to make it so that it doesn't look done. Having the UI look complete is a signal to many business users that the application is complete (even if its just a few static pages without any logic behind it or something built in an interface builder).

Further reading (and links from article):

  • 7
    Sounds like you're proposing some kind of agile methodology... :)
    – Alexander
    Commented Jul 27, 2014 at 18:32
  • 7
    @Alexander Agile helps in this case, but isn't essential. Waterfall can have (deliverable) milestones and customers can be very disappointed at seeing the "it looks done, why are there 3 more mile stones that take just as long?" FWIW, I've had instances where the business user thought it was done because of the screen shot + ms paint in the tech design (waterfall shop) looked good.
    – user40980
    Commented Jul 27, 2014 at 18:35
  • 3
    In case you did not see an expert answer to that video, here it is: youtu.be/B7MIJP90biM
    – ragol
    Commented Jul 27, 2014 at 22:09
  • 3
    I've been designing UI's for the bulk of my programming career and NOT ONCE have I had a client assume that a prototype UI meant that the software was 'almost done'. It sounds to me like the presenters of wireframe UI's are not doing a good job explaining the wireframes up front if the clients are somehow confused into thinking that the project is almost done.
    – GHP
    Commented Jul 28, 2014 at 13:24
  • 2
    +1 for Napkin L&F. That will surely be in my future. :)
    – Kathy
    Commented Jul 28, 2014 at 18:07

It depends: You need a tight feedback loop around your most important piece of functionality

If the core of what you do, the risky and scary part, is some internal engine, then get the core part working in say the console or through unit testing. For example, a protocol parser doesn't need a UI to know whether its operating correctly.

If your cool thing involves any interactivity -- interactivity you need to be constantly troubleshooting, throwing away, and rediscovering -- then a UI-first approach is crucial. For example, I want to build an app to let people interact with a data visualization. The most important thing I need to figure out is if the visualization is meaningful, so I'll likely throw away a half-dozen approaches before settling on one. I'll do this all before writing a single unit test.

There's a fuzzy gray area in between where you get to decide the best combination on how to best interact and validate your code (automated tests? UI for experimentation?). I've personally done both extremes and everything in between, and deciding the right place to be on that spectrum is one of the hardest things I have to decide and is 100% dependent on the type of thing I'm building.

  • 2
    I.e. identify and address the riskiest and most critical components up front so as to mitigate the chance of overruns and/or failure. Whether those components are the UI, business logic, etc..., or most likely, some combination of all the various components.
    – Alexander
    Commented Jul 27, 2014 at 19:21
  • 1
    It really sounds like you're talking about prototyping to me, because if you're still throwing designs away then that's what you should be iterating on - not actual code.
    – Aaronaught
    Commented Jul 29, 2014 at 2:25

In an Agile environment, you might hear discussions of "walking skeletons" or "thin vertical slices". The idea being that since working software is what is important to the user, you build out the software in a working fashion piece by piece.

In the example application you mentioned, you would start with the window and maybe one tab, and make it all work front-to-back in some fashion. Then over time, you would add functionality and therefore tabs on a case-by-case basis, making each feature work as you build it. This is part of what frequent customer demonstrations give you: a chance to show something new working and get feedback on it instantly.

In short, yes, UI work is absolutely part and parcel of a unit of functional work, if you have a UI.

Start with something small that works, and iterate its functionality up to deliver a full piece of software.

  • +1 Always having a shippable piece of something is essential.
    – JensG
    Commented Jul 27, 2014 at 20:37
  • @Jens:"Always having a shippable piece of something is essential" is a canard. At best that saying only applies to a minority of software applications. In the real world, applications which only do part of the job needed aren't useful in the slightest.
    – Dunk
    Commented Jul 28, 2014 at 14:25
  • That's your experiences. I have different ones. Large, real-world projects with plenty of milestones and real customers included.
    – JensG
    Commented Jul 28, 2014 at 16:25
  • 1
    @Dunk: An application that doesn't do any part of the job is less useful than an application that does part of the job. I am not, however, talking about an application that is "done"; I am talking about the order one should build an application. My experience is congruent with JensG: always being able to cut a beta based on what you demoed that week and ship it to the clients immediately makes clients much happier. Commented Jul 28, 2014 at 21:09
  • This is the only answer I can identify with. The others don't even seem to be considering the possibility that good product development doesn't break down cleanly into "UI" and "back-end". It's a question that only a newbie programmer or project manager would ever ask, and not one that an experienced programmer or PM should deign to answer at face value. The very idea of asking which should be "done first" stinks of waterfall.
    – Aaronaught
    Commented Jul 29, 2014 at 2:23

I would recommend making a mixture of both functionality and UI (and getting feedback or testing experience ASAP).

BTW, isn't it the way that most large GUI software is developed? Look for example into the Firefox browser: from one version to the next both functionality and user interface have evolved.


In large (PHP web-based) applications that I work on, I try to get the classes and methods in place first, which return dummy values. This is to establish a pseudo-contract that the other devs can use to implement the UI for.

A secondary advantage to this method is that we can hone the contract / interface as the UI requirements change (and they always change), even before all the code is written and delivered.

  • This is something I'm trying to sort of do. Since my particular project is implemented as a massive UI shell and every datapoint harvester is a plug-in, each plug-in is responsible for managing its own UI components. This way there is no "contract" required for a given person/group of people. The assumption is that the same group of people will be working on a given plug-in start to finish. It's part of the reason I'm designing it the way I am. Alternately, for other projects this is an excellent piece of advice. So upvote from me since it will be useful to others. Commented Jul 27, 2014 at 17:56

What I tend to do is to start with a crappy UI: something that just dumps the variable data on the screen. No fonts, no alignment, nothing actually graphical for a long while. Just "Welcome user x" and buttons called "load pic" etc. What's good about this is you will find out if something in the backend is broken.

As the development proceeds, you might find more things need to go on, or fewer. But at some stage, you will decide the backend is near completion. Now you have a UI that contains all the attachments needed, and you can spend a lot of time doing all the graphical stuff.

Beware though, it's not foolproof. You need a bit of foresight to see certain issues arising. For instance, you may need to research UI components to display the data in a sensible way.

  • And where does the customer come into play in your methodology? Keep in mind that usually your customer only has a very general idea of what they want. It's up to you to figure out how to "draw out of them" exactly what they want so you can build it. Your methodology just built what you think the customer wants but that will seldom be what the customer actually wants. So you've just wasted a ton of time coding something the customer doesn't want.
    – Dunk
    Commented Jul 28, 2014 at 14:30
  • Ah, my "customers" are sitting right next to me, and I have a background in the field that gives me a pretty good idea of what is wanted. Basically we are always close to the end product, UI wise, and I can always get feedback. I hadn't considered the problem of having a long feedback loop. I guess having the domain knowledge is key.
    – Carlos
    Commented Jul 28, 2014 at 14:48

If you use a good milestone and issue tracking system, you can avoid some of these problem because at a glance, management can see how productive you're being. They'll be able to see that you're 80% finished the backend and that the UI is the next milestone; they'll be able to see that you have a set of UI and backend tasks to finish for a specific feature milestone. But it all starts with the project's requirements, and Doug T's answer raises some good points about that aspect of designing a system.


Think in your users/client point of view. A software system is a collection of features that gives this users/clients some value. Of course each one of this features have and UI, a backend and some other things.

Build your system always feature by feature, and try divide in very small features. This way you are always near to have something more to deliver to your customers, remember that software development its not about build the version 1.0 its about going to the version 1.0.1 to the 1.0.2 and so on...


It depends. How well defined are your requirements? How much of the system is UI facing?

From my experience most customers do not know what they want until they see something in front of them. So I normally provide some wire-frames of key UI aspects or deliver the majority of the UI (non working). This allows for the customer to change their mind on features/functions without too much impact as the database design and code structure is still only in design phase - it is easy to amend the design. It is orders of magnitudes easier/quicker to change design earlier in the project then later.

Agile states you should also work on the most difficult items and the most important items first. Fail fast. So once the customer has seen the UI I focus on building small components which are fully functional talking the most important and hardest to implement first so you know as soon as possible if your going to run into any hurdles.

Then you have your sprints and have constant communication with the customer developing both the UI and functional aspects at the sometime.

Not the answer you're looking for? Browse other questions tagged or ask your own question.