[grey-area]

The tools don't really matter; it's the process which is important.

The prototype should be just that - a prototype to be thrown away after starting the product - it should not be used to translate to another medium, or as a final spec sheet which is frozen and cannot be modified during implementation. What you use to prototype doesn't matter - it could be on paper, grid paper, photoshop, HTML, whatever gets it done quickest for you and keeps the client happy. I find sketching on paper then HTML pretty good for prototyping, but whatever works.

Directly translating a static image to HTML leads to a couple of big problems - it encourages an artificial separation between design (which should be how it works, not just how it looks) and development, and it encourages the designer to imagine that their styles will survive contact with the medium and the content (they won't without modification).

[wpietri]

Yes! I have a beef with the notion of "design" as a role. It's a thinker/doer split, which is inherently problematic. Software creation is almost entirely design activity; it's just enough different sorts of design that we need a team to be able to do them all well.

For me, design artifacts are a way to communicate and a way to prime the pump so that you can start iterating in the real medium and getting real-world feedback. For both uses I'm alway seeking the minimum amount of investment in design artifacts, because as soon as the real product is live and in use, the artifacts are all candidates for recycling.