[quoting Phillips, 1 Oct 96.a] I firmly believe all members of the team should be involved in the design. They each have knowledge and experience from their specialty and from previous projects which can enhance a project. It also leads to a more cohesive team later. A programmer may be able to suggest a more efficient type of navigation that the "educational" team members had overlooked. One of our graphic designers almost never says anything in design and planning meetings. However, she absorbs it all, goes away, and comes up with the most wonderful designs very quickly. If she hadn't been in on the design, she couldn't have done this.
I have experienced both situations where everyone was involved in the design as well as when only limited individuals were involved. The 1970's scenario involved everyone which tended to slow down the process (when time was critical) and cause some problems within the team. Agreed, ideas from different perspectives can enhance a project, different perspectives can also detract from the design phase. I have seen more teams destroyed (based on my experience at the University of Mid-America and having worked for three Fortune 500 companies) by large team design efforts. I have also seen some very creative ideas come from inclusive team efforts.
Just to prove that my memory does fail, I recently finished a three year project to develop 13 IMM units for an introductory college chemistry course. (The best outcome may be what I learned from working with two chemists as the subject matter expert's for use in case studies).
The team was small, two chemists, myself as designer, a graduate assistant in chemistry, and a graduate assistant in ID. We developed a rather streamlined strategy for designing the instruction after about three months. Either the ID graduate assistant or I worked with the two chemists to design the instruction. The graduate assistant prototyped the materials in HyperCard and then made printed copies of each card for the chemist to review. (You only allow them to make changes in a stack once before learning of how difficult it is to determine what they changed!) Once we had an approved prototype which had the same screen design as the finished product, it was sent to the programmer. The programmer and his team then created the "final" product in a compiled language.
The major lesson I have learned about chemists is that they have all agreed to disagree and to never agree. Thus, we were faced with designing instructional materials that would be adopted beyond the chemist (yes, the two subject matter experts never agreed) who prevailed on the design. We decided to focus in on a specific concept or rule and the actual visualization of very specific information that had broad appeal and as little interpretation as possible. There was a pre instructional strategy to introduce the most basic information, then the content which was followed by a generative strategy and elaboration. The most widely accepted units were those with minimum content that focused on a simulation or microworld with little elaboration/content.
The greatest amount of time was spent on the design phase, followed by the prototyping and formative evaluation. The least amount of time was spent on the programming. The programmer was literally able to copy and paste our cards into his design. Ample instructions were given about links, navigation, and animations to make this costly task very efficient.
Was the programmer involved in the design? Yes and no. He and I worked on the human interface and layout of the "cards." Then, we designed our prototype stack background to include fields for all the notes and needed information (colors, links, etc.). Basically, he was technician and artist by his own choosing and the limitation of being 500 miles away.