A few more thoughts to share...
An instructional designer designed the package with help of a visual designer and a human interface expert.
But a programmer, a 3D designer, a video producer, a sound engineer, an artist, an animator, a quality assurance expert, and a manager helped convert that design into a good product! And, Human Resource professionals helped all of them retain their sanity!
This is one stage where attention to detail AND professional expertise in each of the above fields can make or mar the product.
Horror stories abound. Here are two of them:
(1) We thought we had brought a package to the alpha stage. And we discovered that some animation frames had two pixel lines and others had single pixel lines. The blame went to the scanner (the hardware of course)! But several days of extra labor went into cleaning double pixel lines to single pixel lines.
(2) We thought we were enhancing the impact of our Quick Time video by shooting it outside in the garden (natural ambiance). Only later did we realize that every movement of the leaf in the background was impacting compression efficiencies. We quickly discovered the joys of blue backgrounds (chromakey).
A few years ago, Michael Allen (of Allen Interactions, Minneapolis) propounded the model of Successive Approximation. As I understand it, it translates into successive cycles of evaluation and modification of the design before the production phase. Within commercial realities, we have realized that the cycles have to successively bring about smaller changes. Invariably, a good rigor in design through support of theoretical, experimental, or experiential constructs reduces the number of cycles. And at some point, we freeze the design because there is no more time and money for design!
But, in spite of all efforts and purported strictness of programmers(!), minor design changes do take place till late into the project cycle. The rule we use is that if the change can be made without introducing bugs and within the project time frame, lets do it. Otherwise, we add it to the list of "Could have beens."
I have only one reference on Successive Approximation--will request Michael to point us to more.
I agree that if too much effort is spent on developing the prototype, the team will find it difficult to accept changes in the design. We have realized that prototypes represent the result of design explorations. They are indicative of what the final product could look like, how the user interface will work, and how the communication will take place (instruction al approach). In a typical project of six months, the prototype would be completed by the end of the second month.
As Rob pointed out, if we make the process too elaborate, it defies its very purpose. Starting with a rapid prototype (the quick and dirty version) helps! We usually do not have a very big budget for this stage. So, we end up using in-house or low cost voice overs, stock music & sound effectss, graphics in place of video, and so on.
Some of the difficulties we have faced in using prototypes are:
(1) The client expects to see it in the final form and is disappointed to see boxes where graphics should be and only partial content coverage.
( 2) We make promises which are a bit tough to implement, e.g., the animation will be much smoother. (Well, the animation ends up being smoother, but maybe not MUCH smoother!)
(3) Since the prototype is not the final product, the team can become complacent and rationalize some comments, e.g., when they see the final product, the navigation won't be confusing!).