Alan Cooper's Keynote speech at Agile 2008

I've just been reading Cooper's keynote address from Agile 2008, and have found several interesting insights. First, he argues that we shouldn't be iterative in the implementation stages of software development... we should be only incremental. I see the waste of being iterative at the implementation level, but I don't know how to validate software reliably without deploying to the customer... but that is where he says Interaction Designers come in. They know how to reliably define the customer needs, how to interpret discussions, and then to translate them into what the developers can understand. Hmmm...



Then he starts talking about some of their training, training I know I don't have. Interaction Designers learn about common reasoning flaws, like (the following is paraphrased from Cooper's slides 82 and 83):

• Loss Aversion


• Value Attribution (initial perception counts more than contradictory evidence later)


• Commitment Bias


• Pygmalion Effect (self-fulfilling prophecies)


• Tyranny of small decisions (too much choice is paralyzing)


• Evolutionary Psychology (we're not machines, and don't always act logically)


• Abilene Syndrome (groups make choices that no one in the group even wanted)


• Memory Distortion (bad things are easier to recall)


• Hawthorn effect (just paying attention to people improves their performance)


• Stockholm syndrome (hostages fall in love with captors)

Interaction designers are designed to distill "requirements" into a clear definition of business need. I can identify with this idea, as I've heard of teams that thrash from one set of whimsical story cards to the next. When I worked in Philly, we had a product owner who was also visionary, who strongly defended the vision against customer requests that were inconsistent with this vision. At my current position we've been saying that we need that vision to be more effective, but no one is playing the role.

Next he argues strongly for prototyping. He says a prototype is necessary for validating the design... and it should be built in a very agile, lean fashion. Then once it's done, rebuild the whole thing from the ground up... I thought that refactoring was supposed to avoid rebuilding to such a large extent. There's a lot to think about here.