The trend in application design and development seems to be starting with the "guts": the domain, then data access, then infrastructure, etc. The GUI seems to usually come later in the process. I wonder if it could ever be useful to build the GUI first...

My rationale is that by building at least a prototype GUI, you gain a better idea of what needs to happen behind the scenes, and so are in a better position to start work on the domain and supporting code.

I can see an issue with this practice in that if the supporting code is not yet written, there won't be much for the GUI layer to actually do. Perhaps building mock objects or throwaway classes (somewhat like is done in unit testing) would provide just enough of a foundation to build the GUI on initially.

Might this be a feasible idea for a real project? Maybe we could add GDD (GUI Driven Development) to the acronym stable...

  • 4
    This is Rapid Application Development.
    – James Love
    Commented Feb 27, 2011 at 21:01
  • Is it useful to write a GUI anyway? Unless it is for a mobile app, a web app or any app that shows images I don't see a need for it.
    – user4595
    Commented Feb 28, 2011 at 1:08
  • possible duplicate of Code First vs. Database First
    – gnat
    Commented Dec 10, 2014 at 12:55

7 Answers 7


Building fast GUI prototypes is a good idea, and I have heard it being used in many projects. Early feedback is valuable indeed. However, it has its dangers:

  • it is very tempting (for managers / users) to use the prototype code further and build the final application on it, which can have very bad long term consequences (this actually happened in one of the projects I have worked on, and it resulted in a "working" product with nonexistent architecture and lots of maintenance headache for us)
  • for the average user, the GUI is the application. Thus once they see a nice looking GUI, they tend to believe most of the actual work is done, so they may get very upset with the "little remaining work" dragging on so long :-/

Mitigating these risks requires active discussion and possibly education of your users and/or managers.

  • 1
    The Pragmatic Programmer covers the prototyping part, and yes, you're totally right. The prototype is disposable code ;) Commented Feb 27, 2011 at 21:49
  • 7
    "For the average user, the GUI is the application". I'd upvote this 100 times for that observation alone.
    – PSU
    Commented Feb 27, 2011 at 21:55
  • @Oscar, thanks for the reference, I practically forgot they discuss this. It is recommended reading indeed. Commented Feb 27, 2011 at 21:58
  • @user13645, I don't claim it's mine - in fact I just added the link to the original blog post by Joel while you wrote your comment :-) Commented Feb 27, 2011 at 22:00
  • 3
    that's why GUI prototyping tools like balsamiq.com showed up. You can show how the GUI will look like and get early feedback from the customer. On the other hand, the GUI created by the tool have a totally different art (a little bit like drawn by hand) so that the customer directly understands that this will not be the final look of the product. And it can't be used as starting code for the product - just as design. Commented Aug 25, 2011 at 12:50

The problem I see with that is that the goal seems to be totally backward.

"My rationale is that by building at least a prototype GUI, you gain a better idea of what needs to happen behind the scenes, and so are in a better position to start work on the domain and supporting code."

This is, in my opinion, the wrong way to look at a business layer and a GREAT way to find a poor, unexpandible design. A data layer that is well designed to express the data completely can be used in any UI. A data layer designed to work for the needs of a specific UI may not be adaptable to anything else, not even minor feature additions to that UI.

Experience with systems designed the way you're talking about lead me to conclude that most designs that use this methodology end up short lived and/or over complicated. They also tend to create coupling between the UI and data layer that should never, ever be there.

Independence of the data layer and UI layer must be encouraged. This is why building the data layer to simply represent the whole data rather than to target a specific UI simply works better in the long run.

Building a prototype can be good for requirements gathering and agreement, but then it should be thrown away. Don't actually use anything from the prototype code in the real product.


I think @Péter is right to suggest that building GUI prototypes is a good idea. I'd like to supplement with the potential pitfalls of providing the user experience in an ass-backwards manner, that is, focusing on ontologies, the architecture and the infrastructure first and the immediate user experience last:

  • The user that you've pushed to far end of the development timeline invalidates your estimations of the data and the way your application is being used.
  • Your elaborate designs that you developed prematurely prove themselves to be self-purposed machinations that have very little or no use in the end.
  • Your application may be brought to such a state where delivering poor user experiences becomes the norm.

You do the guts and then the user gets what came out of your assumptions, while you should be concerned with what the user needs and build the guts accordingly. Why people resort to doing it the other way around is simply because the presentation, that which the user interacts with, from whence the application's behaviors naturally bubble up, is the most complex part of the system that never gets fully explored or people just feel very happy concerning themselves with building things in avoidance to actually having to think through why/what/for whome they're building it. Erecting a huge structure that is structurally sound is child's play, getting it to satisfy everyone's functional (and esthetic) needs is the hardest part.

For each craptastic experience, quirky flow, poorly collocated information, lack of obvious functionality, things that are just plain wrong, instances whenever you've begged to ask "just which genius came up with that?", lies something that ignored, negated or disclosed the user as the forefront of the development efforts.


In general, model should be developed before the view. Once you have a logical foundation of your application, you can build one or more views of that model (for example, you can display data in table or in graph). Usually, the model is more important than GUI. This is especially true for enterprise development where GUI is usually done in a standard way.

However, sometimes the GUI really is the most important part of the application. Sometimes you want to look at a data in a novel and specific way - and you take it from there, and then develop the model. For example, CashCurve is such an application where the point is in the GUI, while the data model itself is standard boring stuff anyone can model in a few minutes. (Disclaimer: I'm not affiliated with CashCurve, just a very satisfied user.)

This is relevant for designing web services or other APIs as well - only there it's known as "contract-first" design.

So, as for everything, there is no rule as to what to design first; sometimes it's model, and sometimes it's GUI. As a rule of a thumb, I'd go with "design the most important part first."

There are caveats to be considered when designing GUI first, such as that user will probably have trouble understanding that application is far from being complete when only GUI prototype exists, but other answers have covered this pretty well so I won't go into details.


I think it is an extremely good way of approaching application design, especially in an agile development environment. Most of the succesful projects I have worked on have started with a prototype that eventually became the real thing.

You have to understand that the GUI is the window into the system (ie. database, filesystem,etc). In a situation where the project requirements are about as vague as a pile of slush, then you won't have a hope in hell in getting a correct solution by starting on the backend. Almost always, the well intentioned backend developer develops a bunch of API which has no relevance to user interactions.

By starting on the GUI, the customer gets a better idea of what they want. As this stage progresses, the developement of the GUI (using mocks and stubs) gives birth to a domain model. This domain model can then be transferred to the backend and the back end developers can start developing the persistance and transactional logic.

And why would you want to throw away the protoype? We are not dealing with stadiums built out of matchsticks. Just refactor the damn thing into something good.


Doesn't sound bad to me at all if the person looking at the GUI understands that it's just a shell and literally buttons and processes do not work (throw new NotImplementedException(); ;)).

If you stick to using an MVC style architecture, I don't foresee any future maintenance or construction problems as the "View" doesn't define any of that kind of thing at all. The "Controllers" and "Model" can come later with any infrastructure you require for scalability/design needs etc.

As for management, draw them a big pie chart with 3 portions, label them "M", "V", and "C". Give the V about 20% and explain the rest of the pie is "TBC" ;).


In any reasonably sized system, what needs to happen behind the scenes is loosely related to what the GUI looks like. The GUI will give you only some of the requirements. There are often many components which don't have a GUI.

After the system is developed additional interfaces (including new GUIs) may be required. Understanding and implementing the business requirements is critical for this to succeed.

Where designing the GUI and other Input and Output mechanisms can help is validating the model. Attributes which are never output, may not be required. (There may be reasons to keep them, but they will likely be audit or regulator requirements.)

As others have mentioned, once you have a working GUI, many clients will think you are done. However, you may have none of the infrastructure behind it. Paper prototypes may be a good option for validating the layout and content of the GUI.

Don't overlook that you may need to adjust the interface after development. I have hear report of a failed checkout interface replacement for a five step checkout process. Much simpler interface didn't give the users the appropriate feeling of security and had a much lower completion rate. Listen to Speed Bumps: The Magical Ingredient in Marketing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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