Metamorphosis

Erik Stolterman and I have been thinking about the issue of turning non-designers into designers (that would be you!). We see our students moving through three transitions:

(I) Pre-emergence
(II) Transitional
(III) Designerly Thinking

Characteristic of each of these transitions is a penetration of barriers. Rather than progression along a smooth continuum, students penetrate these (intellectual, practical, psychological and social) barriers in a step-like function.

I’d like to share these barriers with you and get your comments (David Royer and Sindhia Thirumaran contributed to the list as well). Perhaps you have additional barriers to suggest, or ones to eliminate or modify.

Barriers (numerals in parentheses indicate the transitional stage(s) where the barrier occurs)

1. Design definitions. Naïve designers’ conception of HCI/d includes mostly graphic design and interface design; experienced designers also include interaction design, experience design, emotional design, and systems design. (I)
2. Best solution. Naïve designers hold onto the belief that there is a best solution; experienced designers believe there exist many solutions and judged by critical criteria and presented through a design argument or explanation. (I)
3. Technology-centered vs. human-centered. Naïve designers focus on the technology; experienced designers study human behavior, motivation and need. It’s very difficult to “let go” of gadgets and things; there’s an over-fascination with techno-fetishism among naïve designers. (I, II)
4. Me and we. Naïve designers defend their own designs; experienced designers look to their team for inspiration and solutions. (I, II)
5. User research. Naïve designers underplay the role of user research; they know what people want. Tools such as personas are resisted rather than embraced naturally in the design process. Experienced designers do not make assumptions about human desires and motivations; they study it instead. (I, II)
6. IT domination. Naïve designers tend to overemphasize efficiency, effectiveness, scalability; experienced designers include experience and emotion. (II)
7. Idea loyalty. Naïve designers hold onto a single idea; experienced designers engage in systematic exploration of multiple ideas. (II)
8. Algorithm / design paradox. Naïve designers expect to memorize algorithmic solutions to problems; experienced designers learn to deal with ill-structured problems, seemingly paradoxical situations and design thinking. (II, III)
9. Critique culture. Naïve designers worry about school grades; experienced designers welcome critique. (II, III)
10. Notebook. Naïve designers sketch for a particular project; experienced designers sketch continuously, deriving inspiration from all contexts. (II, III)
11. Role. Naïve designers are learning what they do and how to do it; experienced designers begin to defend the position of design in a multi-person development team made up of designers and non-designers. (II, III)
12. Research and philosophy. Naïve designers find solutions in the HCI literature; experienced designers explore philosophical foundations of design as well. (III)
13. Reflective designer. Naïve designers spend little to no time reflecting on how they are designing versus experienced designers who can look at themselves “out of body” as they design. (III)
14. Omnipresence. Naïve designers see design embedded in objects; experienced designers see systems that affect designs and designs that affect systems. (III)
15. External / internal. Naïve designers find external answers to design problems; experienced designers begin to look internally and introspectively for inspiration and resolution. (III)

logic of failure

We’re in the middle of designing solutions for a complex, real world problem, and it reminded me of a book I read some years ago: The Logic of Failure: Recognizing and Avoiding Error in Complex Situations, by Dietrich Dörner. The author tells a story of a city council and its mayor trying to fix the volume of traffic, noise, and air pollution in their downtown area. To solve the problem they introduced speed bumps and the speed limit was reduced to 20 miles per hour. But the results were unexpected: 1) the speed bumps forced people to drive in a lower gear, thus increasing the noise and exhaust fumes; 2) but because of the reduced speed, people spent more time shopping, and this actually increased the number of cars in the downtown area; 3) eventually fewer and fewer went downtown because of these reasons; 4) people started shopping in a near-by mall; 5) downtown stores, once thriving, were facing bankruptcy, and 6) tax revenues were significantly down. “The fate of this environment-conscious town demonstrates how human planning and decision-making processes can go awry if we do not pay enough attention to possible side effects and long-term repercussions, if we apply corrective measures too aggressively or too timidly, of if we ignore premises we should have considered.” [p.2]

It seems we’re wired for this kind of ad hoc thinking. Hunting, building a fire, or chasing away a wild animal does not have much significance beyond the act; “…our prehistoric ancestors did not have to think beyond the situation itself. The need to see a problem embedded in the context of other problems rarely arose. For us, however, this is the rule, not the exception. Do our habits of thought measure up to the demands of thinking in systems? What errors are we prone to when we have to take side effects and long-term repercussions into account?” [p. 6]

…

The technique of asking question after question about your design may prevent this kind of failure. Rich Gold’s analysis of smart houses prevents this kind of thinking and leads to solid design arguments. I hope some teams are using this technique and thus avoiding failure.

framing

One of the most important tasks for the team facilitator is “framing.” It’s a way for the facilitator to tell the team what is coming next, why it is important, and what should be the nature of the outcome. A team meeting should be a sequence of frames beginning with the check-in, the main part of the meeting, and then the postmortem or team reflection. Here are some examples:

The check-in frame (of course using your own words):
It’s good to see everyone again. Let’s take a couple minutes at the beginning to share what’s happening in our lives and then we’ll check-in and get down to work. In this frame, the facilitator has set a goal, a limit, and then once that is out of the way, the team can focus, indicating their focus by checking-in.

The goals frame:
Today we have two hours for our meeting, ending at noon today. Here are the goals for our meeting: [list 2-3 goals on the white board] If we can accomplish these, I truly believe we will move our project forward in an important way.
Notice that the facilitator is telling the team why it would be good to accomplish these goals. Of course, this should be followed by a team vote: I propose these goals. One, two, three… [thumb voting]. If there’s a “thumbs down,” the facilitator should ask, What would it take to get you in?

The postmortem frame (10 minutes before the end of the meeting):
We’ve reached the end of our time together. Let’s reflect on our meeting today. Let’s discuss what went well and what didn’t. From this we’ll have a better meeting next time.
Again, the facilitator is framing the next ten minutes by saying what will happen next, how the conversation should proceed, and why it’s important to have this conversation.

Framing can make a huge positive difference in team meetings. It’s one of the most important tools available to the facilitator.

What other team techniques have you found to be useful?