In a recent email conversation with a designer/client manager friend/collaborator, I wrote the following about a process for Flash development. I think there is something in this…

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…