Ah, a chance for process mind dump. My favourite! Here’s what I think
off the top of my head….

Yeah, I know what you’re saying about the tendency for clients to
change their minds when they see things in action. Generally it is
hard (for them especially) to visualise things out of context and
without seeing it in action. It’s what a prototype is for – one
expects it to change in the next iteration after feedback.

I suppose you need to offer a certain number of iterations at each
phase, and you agree beforehand that by the 2nd, 3rd or 4th (or
whatever maximum budget permits) feedback session you will have
reached a final version, or renegotiate terms. Obviously the better
defined the goals and idea is from the beginning, and the better the
feedback and communication with the client, the more worth you get out
of each iteration.

Internally we then discuss behaviour/presentation that is on brand and
in scope and answers feedback so far, and make sure we are developing
to meeting those goals.

I suppose one should throw some basic user testing into the mix too…
I usually show it around the office and send links to a couple people.

See it as building up from the essentials. Your first prototype was
actually your static photoshop designs. Next we will add click and
load of linked content, and then we will add transitions and tactile
mouse interaction behaviour, then we will tweak and polish. (there. 3
phases)

As for the hard work up front… I think a large part of that can be
mitigated by good client communication and explanation of ideas, so
the designer/developer isn’t trying to guess too much at time of
execution.Brief the designer/developer effectively so they understand
the goals, and can add some of their own understanding and creative
flair to the problem solving.

Review internally frequently – we can make the mental leap to how
things behave a bit better than clients.

Also, as you know I like to develop with reusability and
configurability in mind, so swapping one behaviour for another, or
enhancing one aspect of the behaviour is more about adjusting a lever
than rewriting much more code. I think the core to making this stuff
work is getting the correct subtle balance in the various parameters
that combine to affect the overall behaviour. If we know we are
starting in the right direction, the post client feedback should be
met with this sort of adjustment (and usually is, unless they hate the
whole concept and we have to start from scratch.)

There you have my thoughts! Happy to discuss adjusting and solidifying
into a more structured process…