Steve Harrison, Deborah Tatar
Some design methods are used but not taught. Others are taught but not used. That is the problem.
Arguably, the most useful methods we can teach our students are the most neglected in our classes. When we look at people in design practice, we see variations of affinity diagrams. We observe clumps of Post-its on walls. We see information architects asking users to sort cards into clusters of preexisting or novel categories. The K-J method formalizes these techniques as a group process. Yet these methods are commonly relegated to a single perfunctory in-class exercise, and they are not widely represented in the research literature.
Likewise, personas are treated as an almost embarrassing afterthought. Yet they are widely used in industry. Other methods are too simple to even receive discussion. For example, the Zwicky, or morphological boxa method that is almost as simple and flexible as paper itselfmay never be mentioned at all. Or, if it is, it may show up only as a technique for "defining the design space," not a resource to be used over and over in different ways.
Complex techniques, such as usability engineering, agile design, scenario-based design, and claims analysis, receive more attention. There is nothing wrong with these techniques. But their use in practice is much more limited than that of many neglected or untaught methods.
We have a few theories about why HCI design instruction is unbalanced.
Simon says. Abstraction is overrated. We single out Herb Simon for some of this: In addition to his many accomplishments, unfortunately, Herb Simon's The Science of the Artificial did create at least one disservice. By taking the notion of design to dizzying heights of abstraction, he made it difficult for interaction designers to see particulars in disciplines that traditionally took design activity as central .
In some fieldseconomics, psychology, computer science, and, indeed, engineeringan idea is often considered better and more powerful if it is more general; a system that encompasses an entire process is often considered better than a system that implements only one piece of the process. Consequently, simple, reliable design methods become less valued than more general, all-encompassing ones and disappear from consciousness. This may be useful in many of our allied disciplines, but not so in interaction design.
Dream big visions; dream big methods. Novel methods are overrated (or at least more highly rated than old methods). Methods are taught as if they were the research or design itself. "Hey, we're designers too! We have big visions and design big systems! We want to share them with our students!"
Special methods for a special discipline. Many interaction design instructors believe interaction design intrinsically requires methods unique and specific to HCI. They avoid the methods of its root disciplinescomputer science, cognitive psychology, industrial design, graphic design, and informatics, to name a few. Perhaps the fear is that borrowing methods might premiate one foundational discipline over another, or that design students will lose their tenuous grasp of the ineluctable nature of interaction.
Let's use their methodsthey must know something we don't. Just as there are those interaction design instructors who believe that interaction design requires unique methods, there are those who try to use design methods of engineeringparticularly software engineering. Of course, implementation often takes interaction design into the realm of software, but that is not a reason to mold interaction design processes into the shape of software engineering. Furthermore, the issues of interaction design are just as likely to involve issues of other disciplines as well as software businesswhy not use the methods of marketing or electrical engineering?
Perhaps those are not bad ideas. In fact, the techniques that are used in practice come from many sources. But they engage designers easily, speak easily to people inside and outside the design process, and can be plugged in when needed and dropped when not. They are very simple. Most important, they are appropriable.
And this is where the true pedagogical problem arises. The methods may be simple, but learning to appropriate is not. "Good designers copy; great designers steal" . To appropriate appropriately, the designer must know what the design situation is. Workaday designers design for the same situation over and over again, often without reflection on the repetition of process or the appropriateness of the methods. But good and great designers often switch design situations. To train good and great designers, we must make students aware of their design situation and give them permission to make and remake methods as needed.
Academics often describe the design situation in terms of a brief or problem statement. But on the job, employment, client relations, and concerns of practicality are just as much in play.
A few years ago, we wrote a paper with Mary Beth Back called "It's Just a Method!" about trying to teach HCI students the Method of Methods. The idea is that students learn many methods and then have to appropriate them in the course of design. The paper has been cited pretty widely but suffers from simplicity. The Method of Methods can be reported as research only once. But that does not make it less important as pedagogical practice.
One aspect is teaching a number of variations of one method and then having students explain how they are basically the same thing and how they were fashioned to be appropriate in a particular project. For example, the morphological box can be used to describe the design space, become a concept-selection matrix, a combinatoric tool to bring together disparate ideas, and even a way of identifying problem structures. Some students do not see the connections immediately. We have them poke around the website of the Swedish Morphological Society (http://www.swemorph.com/) to get a feel for how this can be a rich, varied, and appropriable method.
Another aspect is encouraging students to appropriate from scratch. This is not hard: As John Zimmerman of Carnegie Mellon is fond of saying, "Design methods are like toothbrushes. Everyone uses them, but no one likes to use someone else's." Method redesign becomes an active part of design learning. This means using methods over and over and asking at opportune moments what methods the students might use or repurpose for the situation at hand. The "owned" or appropriated method becomes the favorite pen with which the design is written.
Brainstorming is both widely used and taught. Brainstorming is important. On one hand, it is often taught as early as fifth grade and occurs across the K12 curriculum. On the other, there are design-education programs built around brainstorming. For example, Stanford's design program has long emphasized brainstorming as a key method in ideation and problem solving. Not surprisingly, brainstorming is ubiquitous in design practices.
But brainstorming has a number of drawbacks. First, it can look like a solution to every design situation, obviating the need to consider the process of design for the situation. Second, it can dichotomize the social part of design into (1) a funand sometimes competitivebrainstorm coupled with (2) a set of implementation roles often conducted without much use for method. Worse, brainstorming is often a perfunctory nod to the gods of good design. Teaching brainstorming plain and simple is not enough.
Our point is that designers are charged with designing their process of design. Getting specificity with regard to a design situation is one key reason to employ a designer. And this is what it means to teach design.
We expect to hear from exponents of particular methodologiesboth academics and practitionersabout the value of their method over other methods. Enthusiasm is good, especially in research. But we also hope that a few interaction design faculty will appropriate the Method of Methods or at least focus on getting students to master their own process of designing.
©2011 ACM 1072-5220/11/0300 $10.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2011 ACM, Inc.