UX and Agile

I was scheduled to do a talk today called "Building Great UX with .NET" today at the SouthCT .NET UG.  Well, mother nature had other plans, and I had to reschedule for 8 April.  So I have this wonderful presentation all prepared and nowhere to do it (yet). :)  I'm sure it will surface more than once throughout the year.

As I was collecting my thoughts and research for the presentation, I got sucked into a related discussion on the Interaction Design Association discussion list.  I was, frankly, shocked that there are advocates of waterfall process in the UX pro community.  It's really odd, actually, because some of them seem to think that agile is this weird, engineer-centric approach to doing software and feel they can't do the design they think needs doing for good UX. 

It seems to be an extension of the misperception that agile means anarchy or, at least, that agile means you can't do any up front design.  I pointed them to Ambler's intro to initial agile modeling as well as the results of the most recent survey they've done that shows how agile tends towards greater success in software.  I could also point to his essay on "proving" agile's worth, but after seeing the latest reaction--"How can this method possibly create new innovations if it is essentially the same old requirements/design/develope test process?"--I tend to think it's not worth the effort.  At least that person is clearly not willing to invest the most basic level of research and open mindedness to understand what agile is.  I think anyone who's spent five minutes reading up on it knows it's not the "same old process."

In any case, one of the things my presentation deals with just that--where and how to plug UX pros into an agile process.  Of course, agile being the adaptable beast that it is, I don't dare presume that my suggestions are the only right way, but they're based on what seems to work (as well as what makes sense).  The basic gist is that you plug them in where they need to be plugged in! :)

You have interaction designers?  Plug 'em in up front and as needed during iterations.  They create your basic high-level plan for your interactions (like the outline of a story).  As you build our your iterations, they have "chapters" of their story to "write," working closely with the devs and stakeholders.  If refactoring is needed, they're right there as needed to do their part. 

Visual designers plug into the process in a similar manner.  Up front, they might want to come up with an overall theme, maybe design the logo (if you need one), pick the color palette, come up with some initial mockups for the design even, though probably shouldn't get too detailed with mockups up front.  As you build out your iterations, more firmly nail down particular wire frames, they can hammer out the particular designs and refactor as needed.

Usability pros also can plug in throughout the lifecycle.  They can do usability research up front (observing users, interviewing, etc.).  As the particular interactions are designed, they can participate in lightweight testing (e.g., paper prototype testing), and of course, as the iterations are built out, they can do more in-depth usability testing with user observations and provide input for refactoring of the app.

Information architects build out your basic information framework up front, establish applicable organizing principles, any known taxonomies, and any known architectural requirements that are needed to facilitate the IA.  As the iterations are built out, they participate to ensure their vision is followed through and to fill out details as needed.  If there's a technical barrier during implementation that makes the desired IA unworkable, the IAs can refactor or help the team figure out how to overcome or work around it.

Not only is this workable, it could actually help UX folks and devs and architects work better together, gain better mutual understanding, and even maybe build better software all around, which is, after all, the point of agile as well as the point of UX.  They're made for each other.