Part 3 of a 4 part series:
We talked previously about our cognitive limitations. Here I list a subset of the heuristics I’ve discovered across design practices and from experience. I’m sure you’ll find some that seem obvious, and have others of your own. However, I still see instances where these principles would have helped, so I’m tossing them out there just in case.
Team Design: One problem is covering all the required areas of expertise. As was discovered in the early days of multimedia, designers should recognize and acknowledge the spectrum of talent required to properly develop a project. In particular, there should be expertise on the team for the content area, the educational design, the interface design, the programming environment, and each media area to be used. The management style has to allow the contributions of these experts to the design, and to resolve any fundamental contradictions only upon assessment of each point of view. The saying is that the room is smarter than the smartest person in the room, but my caveat is that is only true if you manage the process right. But diversity helps, and you want to find a way to involve diverse viewpoints early on, so ensure a suite of talents on the design team.
Egoless Design: Hand in hand with the above is the requirement for egoless design. Each team member has to feel comfortable contributing to the overall design and willing to offer and receive constructive criticism. Egoless programming was the source of this approach, but it holds true fo all group endeavors. The members have to recognize and respect the contributions of each other. Team leaders can facilitate this by displaying the same quality themselves. For instance, the opportunity for deliberately silly ideas can support a willingness to take risks. There should be explicit discussions of process as well as product, as this is likely to prove valuable in not only leading to a high quality of output but in leading to improved capabilities of the team members.
3 Strategies Design: While creativity in the design process can contribute to selecting a good design, all designs will benefit from testing and refinement of the design. Three strategies from the field of ‘user-centered design’ can be used to characterize an appropriate approach. This process is captured in the notion of iterative, formative, and situated design, where successive iterations of the design are tested with real data and real users and the results are used to further inform the design process. It has been reliably demonstrated that single passes at design fail for reasons specifically related to lack of appropriate testing. In short, the waterfall approach doesn’t work. We’ll find questions we can’t answer on the basis of existing information and we’ll have differing opinions. Prototype and test! Also…
(the Double) Double P’s: Once some designs are generated, it is necessary to start producing limited-capability versions, or prototypes (different from the use of the term for the evolutionary design model), for testing to feed back into the design process. The prototypes that are created should be of increasing fidelity, but it is tempting to start prototyping them on the computer However, this can lead to functional fixedness. A colleague many years ago had a rule for his team that no programming should proceed until a complete ‘storyboard’ has been completed on paper. This leads to a prescription for the Double P’s: Postponing Programming and Preferring Paper. User experience work has found that paper can be extremely valuable for experimenting, prototyping, and testing. Get your answers before you spend lots of money and time!
OK, one more list of heuristics coming up. And I look forward to yours and your feedback.