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.

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!

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.

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!

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.