in Web-App

Design or Develop First

Should a web application be designed first, or developed first?

It’s obvious that designers and programmers feel differently about this.

Take this perspective, for example (all quotes from comments here):

As a programmer, I produce ugly-but-functional designs for the HTML monkeys to tart up however they like. Trying to do it the other way around is a recipe for disaster.

And this one:

I would say both things have to be done in parallel rather than first coding and then designing or the reverse way. The final product has to be clear enough so that the designer can work on how to present it while the coder is implementing each functionality.

What do you think? Can it be both ways? With our web application that we are building, our process has been to design everything in Photoshop before writing a single line of code. This may sound backwards to some people, but it has allowed us to see what the user will see, and show people our application.

Our web app would not have been as cool as it is if we hadn’t started with design.

There have been a large number of design improvements, and functionality improvements that have been made as a result of seeing something designed.

It’s quite possible that many people think of the design as purely aesthetic, when I see both the beauty side, as well as functionality and ease of use.

What do you think? In your projects, do you begin with code or with design?

Continue Reading:

Write a Comment


  1. *If done correctly*, whichever job (development or design) comes first should make the job of the other’s easier. The problem is that there must exist something that defines “correctly”, which is usually done in the form of specifications. So if there are no clear specifications for either party to go on then I don’t think it matters who does their job first, because the party that does the job first will therefore be defining the specifications for the job.

    But to answer your question: as a developer, its nice to have a visual foundation/reference beforehand that shows me how the user is going to interact with the website.

    I can see design before development to be a problem, though, because designers like features. More featuers can mean more work and a tighter deadline.

  2. My method:

    1. do rough mock-ups of the main screens first (unless I know exactly what’s needed, or it’s only a simple function)

    2. Code it

    3. Put the fancy pants on it.

    I’ve worked on projects where the designers insist on designing everything first, and then do so with no consideration on whether something is doable or feasable within, dev-wise, and then get all p’d off when I don’t implement every single thing on their lush mocks. Damn designers! :)

  3. I think the best approach is to build an HTML prototype first (no backend or very little backend programming). You should really avoid any visual design (images, colors, etc) discussion and focus on the structure: functionnalities, layout, forms, etc.

    The problem is, as you stated, people often mistake design with aesthetics.

    In my experience, designing a web app is best done in HTML directly as the user can interact with it. You can easily show it off, it’s the next best thing to the real thing. A photoshop mockup does not have any dimension, it is an image with no interaction. Unless you can play with the prototype, you only have an idea of what it will be. It’s easy to have a false idea or to get in a situation where different person will have a different idea.

    The programmer is usually bad at writing good html: the prototype should be built by the designer. But the programmer must also be involved. They should work hand in hand!

    I would definitely recommend coding the front-end directly in the html with little logic. You do not work on the back-end until everybody is on the same page. I do not believe in throwable prototypes (such as PS mockups), the prototype should be the basis for the real app.

    At work we use exclusively Java / Struts, which is not really prototype friendly (lots of xml, config, etc). I used RoR to prototype the last four apps I worked on with great success: it’s fast to work with, easy to learn and code. I can translate the ruby html templates easily to jsp, it’s only a matter of replacing a few tags for each screen.

    Hech, the client can sit with me at my computer while I work and show him the modifications. Discussion is facilitated because of the tool, it does not interrupt the flow. This is what I would call Extreme Prototyping!

    The trick is to find the right tool for your need that will lessen the workload for all parties involved in the process.

  4. Mark > A designer should know what’s feasible and what’s not in the context of your project. Otherwise it is not a real designer.

  5. Every project I’ve worked on the design gets completed before anyone starts coding. It’s also the way I prefer to work because I can determine which features get added and how they get implemented.

  6. Here’s my process:

    1) Plan the code and how it will work

    2) Get the design all worked out in Photoshop

    3) Create HTML and split up images in Photoshop

    4) Create the code

    5) Tweak the HTML, code and maybe revisit Photoshop

    I do things in this order because if you have the code planned out it makes it easy to know how to design it. Then once you have the design all done it makes it easy to produce the HTML. Then you have the HTML in which you know what the elements of the code need to be and where to put them.

    As soon as the code is done, or during code creation, you will have the full HTML template in which you can apply the code and fully visualize how it will all work together.

    Once the code and design have been put together tweaks can be made. This process will allow the design and code to grow and mold around each other it’s like marinating a good piece of steak.

    And i love steak!

  7. Do a rough plan on paper of how the app will work (I find in photoshop I end up playing with minor details that don’t matter).

    Then produce the html version and get it working barebones, so that you can work on the functionality.

    Once the functionality is there build on the nice pixels.

    This is just to get started, once you are moving it sohuld be continuous improvement anyway.

  8. With the project I’m designing for now, I’ve been producing Photoshop comps that define the functionality and thus, the code. We’re already a couple months in so a lot of the work has been finished, but next time around I’m going to do my comps in plain HTML. No fussing over colors and other aesthetics when the actual UI design isn’t finalized. Its been a pain in the ass and I’m learning my lesson.