Agile Project Planning

ExtremePlanner: Agile Project Management for Distributed Software Teams
Click For Your Free Online Trial

Sunday, September 25, 2005

Agile Interaction Design?

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.

For more on agile tools and techniques:

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams


  • I know my comment is not timely as I stumbled upon your post when I was googling interaction design and agile. I was looking to hear from other designers on how they've transformed their process to be more agile... though I was suprised by your notion that agile does not apply to interaction design. I've got a unique perspective on this as I've both been a successful interaction designer and a successful engineering manager (of a high profile XP project).

    In my opinion, many aspects of business process can be encompassed by 'agile'. For example, marketing, sales, and product management can apply agile / lean principles to their own process (I've seen marketing teams have daily standup meetings and dole out tasks that are tracked with burn down..). So, at a minimum, a product development team performing agile should function very different than a waterfall team. All members of the team (QA - quality, documentation, interaction design, etc) need to embrace the concept of iterative development, and continuous integration so to speak.

    When I started my job, I was brought on as an interaction designer at the very beginning of the project (green field). There was about 3 months of time between when I started the company and when developers actually started cutting code. For me, much of the time was spent ramping up, getting familiar with the ideas, and working with product management on building out wireframes based on user stories. By the time the developers had started their first iteration, I was no where near complete with my 'system design'. The development team started with the designs / wireframes I had, and implemented what was done at the start of their first iteration. As my understanding of the product evolved, so did the interaction design of the product. Initially, this was very disruptive to the team as implementing and reimplementing the UI was very difficult. The team refactored the UI such that it was abstracted out of the core code base was templated. As I continued to evolve the design, we built in time for the engineers to implement the changes and baked that into the process. It became an iterative design and design implementation process that baked in several feedback mechanisms to ensure we were delivering the optimal user experience.

    So, what am I saying? Cooper is wrong. Software development is changing. Practitioners have the ability to adopt an iterative approach to UI design that is tightly coupled with iterative (agile) engineering practices. Jacob Neilsen is known to state that interaction design is an iterative process. You're always hitting a moving target... it's unfortunate to see that not many folks have married interaction design with scrum or other agile methodologies...

    By Anonymous Anonymous, at 11:48 PM  

Post a Comment

<< Home