In the book About Face 2.0, authors Alan Cooper and Robert Reimann detail the role of the Interaction Designer on a software project. The authors promote the idea that this new role is not something that a software developer would typically do, but requires a new breed of professional.
At the risk of oversimplifying, an interaction designer is essentially responsible for user-centered design, which consists of discovering user goals, and trying to design solutions that meet as many of them as possible. One of the primary tools for this is developing "personas", with unique needs, likes and dislike, and of course, goals. The authors believe that this work should occur before any software is built.
While I strongly agree with much of the material in the book, it did make me wonder about how this might work in an agile setting. Agile methods tend to avoid Big Design Up Front, but that tends to mean overly complex design documents that guess about the architecture and implementation of the system. Some agile proponents also avoid documentation other than index cards with story descriptions, and transient whiteboard sketches.
So can an agile team incorporate Interaction Design (I'm going to call it ID from now on) ? Well, to paraphrase Cooper in an interview with Kent Beck, father of XP, yes, as long as the ID team can do their work first, before the programmers get a crack at it.
I'd compare this to the recent Joel Spolsky article where Joel takes a shot at XP for not encouraging up front functional specifications. He argues (and I agree) that functional specs done right, and done first, save a lot of time in the development process. I think Cooper and Reimann are less concerned with the time involved, but certainly believe that ID produces dramatically improved solutions that make users happy. And, like Joel, they believe it should be done up front.
An ID team probably becomes the voice of the customer in Agile methods, and as such should be working closely with the development team as well as the users. In that sense, the ID role may be more of a liaison between customer and developer.
So is ID compatible with Agile? I think it is, just as functional specifications, formal testing, documentation, and other traditional software disciplines are. The danger would be if the work of an ID team turned out to be inaccurate or ineffective, but I think this can be mitigated by following what I believe is the Golden Rule of Agile: Deliver Early and Often.
Previous Topic
