I'm curious on your personal definition of design?

You seem to be implying by your question that you'd consider producing an HTML prototype as something distinct from design.

Personally I'd tend to consider producing the HTML as part of the design process - for certain kinds of product anyway.

Why isn't it a "design" thing?

Thinking about this more, I really think you need to be wary with HTML prototypes at any point in the process. I know I have mentioned this before, but if you have a pretty HTML prototype, especially one that "functions", you are going to run into problems with your business people - the ones that don't really know the difference between a static HTML page and a fully functioning web application with a ton of back-end code supporting it. I can't count the number of times where I've had business people review an HTML prototype and expect the application to be completed in just a short time, since "it looks like it's done as long as you change the color of the links" or something like that. A functional HTML prototype can cause a significant amount of work trying to explain to these people why your project is going to take another 3 months to complete.

Josef - Personally, that much wasted time would drive me bonkers.

1. User flow-maps (Work flows)
2. Sketching wire-frames of in iPlotz
3. Click a button to export as functioning prototype
4. Hand over to designers/developers to make it pretty while respecting my UI decisions

I can't imagine manually building HTML protoypes after sketching on paper. (I am not at all criticizing your process, just saying I can't imagine doing that anymore.) Wireframing is so much faster these days using tools like Balsmiq and iPlotz - and when changes need to be made (nav elements added, removd, and so on), master templates can make that replicate across all of your wires.

By the time you're done with your wires, your protoype is finished. There is no step 2 to having a working protoype in my workflow.I then present to the team, we make whatever revisions, I update iPlotz, hit save and my protoype gets updated instantly - no additional re-coding or editing. I can test usability and interaction with my working prototype for no more effort than it took me to create the original wireframes.

I'm curious to learn why you've opted to dive right into developing a higher-def wireframe in HTML, instead of using one of the more intermediate tools (i.e. throwaway prototypes) to work out the design. Especially as you mention that this takes up most of your day.

I use a different approach. I do sketches, or even paper prototypes and then progress the design into an interactive prototype in iPlotz. Next I record a quick Jing demo as well as circulate the interactive prototype around, to get some initial feedback.

I do a few iterations of this before we spend any time writing code. We use it as a litmus test to ensure we're spending time designing the right thing.

I have found this to be a quick, yet effective way of doing rapid iterations, which enables me to get valuable feedback from both internal stakeholders and customers.

paper & pencil -> HTML

Before coding css/html you should draw first, software engineers haven't found yet a faster way to conceive a UI than drawing it on a piece of paper.

HTML prototypes before design? What type of design are you talking about? Detailed software design? Sure, HTML prototypes make sense. But any other type of design (high-level software design, UI design, IA, etc.) are all pretty much required before you can make an accurate HTML prototype. The HTML prototype might be one of the final steps in UI design, but I don't see how you can even entertain the idea of creating them before significant design is completed.

If it's very easy for you to do HTML prototypes, that would be great because it's closer to the actual product (if it is) than other prototypes.

If not, you can always resort to paper prototyping or using tools like Balsamiq, which supports links. A wireframe can have links to other wireframes.