Agile Book Club: Interaction Design
Posted by Jeremy Voorhis Wed, 30 Aug 2006 16:08:00 GMT
To begin, I will share an email conversation that Joe O’Brien and I traded this morning:
Joe, You made a wise purchase ;) About Face 2.0 isn't bad; it's full of some great advice. My biggest gripes with it are the follows: * It declares that programmers are just unfit for interaction design. * It advocates for waterfall development. * Cooper has a defensive tone whenever discussing his beloved discipline of interaction design. * The web chapter is dated. If you can get over all of those things, it is full of great ideas, specifically about working with personas, and data entry and retrieval. You might also like Rapid Contextual Design - it is a book that builds on some of Cooper's ideas and presents them in an agile-friendly way. What I like about Design of Everyday Things is that it creates a framework for thinking about usability problems, rather than handing out specific advice. I think this allows for much more creativity, and gives you more depth when supporting your design decisions. Cheers On Wed, 2006-08-30 at 09:35 -0400, Joe OBrien wrote: > The Design of Everyday Things just arrived last night. You're right, > it's been great so far. I'm really stoked about it. > > > I also went ahead and purchased About Face, I know it's not all > great, but I'm still looking forward to it. > > > Thanks again, > -Joe > > > > ======================= > are you living on the edge? > theedgecase.com
This got me thinking: as developers, we invest a great deal of time and money in technical books. I value good recommendations that I receive, and I also enjoy passing them on. I also enjoy a good discussion about the content with other readers.
In order to foster this type of dialog, I have created a new Google group: The Agile Book Club. The group is public, and we would really like to have your input!

Great idea Jeremy! I’m signed up.
Jeremy,
The approach to Interaction Design outlined by Alan Cooper doesn’t really push for any specific methodology. Based on what I’ve read… I wouldn’t imagine him to really accept any of the development methodologies. He focuses on goals and how to build elegant solutions. Not a strict, waterfall approach, which each team passes their work to the next team. Cooper argues that teams need to work together through that process not pass it off.
Dave Churchville posted an article last year titled, Agile Interaction Design?, which discussed how the role of an Interaction Designer (ID) can be compatible with Agile methodologies. ”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.”
Another interesting read is a discussion between Alan Cooper and Kent Beck where they duke out their differences. They discussed how ID and XP could work together and Cooper had the following to say.
In the end it comes down to a healthy cycle of feedback, whether that be between clients, developers, or interaction designers. The waterfall model is quite different in that everything is specified upfront and doesn’t provide a clear process for collaboration between each team on a project.
“Some” developers could very well be capable and good at being involved in Interaction Design and if you’re working in a small enough team this should be encouraged.
I forgot to cite the conversation between Kent Beck and Alan Cooper… bad me.
Read it here!
:-)
Intereseting post. As for the book club, why not start the club on something like librarything (www.librarything.com) . There are plenty of people there and many of them are software developers.
Note: i dont work for librarything. the only reason i mention it is that i have found it helpful in managing my library.
Petro,
I’ve never seen Library thing before.
I just signed up and added an Agile group in like 15 seconds.
@Robby
I believe interaction design can be practiced in an agile way. More and more agile shops are adopting goal-directed approaches, and I believe it is for the best. Furthermore, my statement about waterfall development was only applicable to an attitude pervasive in About Face 2.0.
The diagram on page 6 of About Face 2.0 – coupled with the persistent notion that developers are not capable of getting interaction design right – are not constructive in the context of an agile development team. As time progresses, the division of labor between developers, interaction designers and numerous other roles becomes blurry. In real working situations, many developers wear all of these hats. While it is good practice to delegate responsibility for the quality of interaction design to a team leader, good software behavior is such a cross-cutting aspect with many details lying beneath the surface that it cannot be planned up-front on its own.
My conclusion is that developers should learn to become sensitive to interaction design. Software projects will improve in situations without a dedicated interaction design team; supportive application design and smooth integration will take place within teams that do include dedicated interaction designers.
Good point. They should!
In some teams it’s important to delegate responsibility to those who are naturally more empathetic towards users (people). A good sign that you’re not a good fit for this role is to look at some of the error messages that you have written in your application that users are exposed to. All too often I have seen error messages that only make the user feel stupid.
In The Inmates are Running the Asylum, Alan Coopers suggests that “programmers want control and will accept complexity as a trade-off whereas people want simplicity and will accept less control as a trade-off.”
Of course, programmers don’t often like to hear this because they believe they can solve problems and user interaction is a problem and they think they can solve that too. My assessment of Cooper’s writings has been that he thinks that developers have had their chance and it’s time for them to step aside and give someone else a chance to try and solve this problem.
I find Cooper’s writing thought provoking, but his consistent negative generalizations of “programmers” gets tiresome. Personally I believe there are quite a few programmers who desire simplicity and elegance, and Cooper is building a bit of a straw man in order to have an attractive message for frustrated management.
Yeah, not all programmers are created equal. ;-)