ux – Rypple

UX in an Agile shop

James Wu ~ February 19th, 2009

In October, I had the pleasure of spending a few days in Boston attending UI13 and in particular, Agile development guru Jeff Patton’s all day seminar on bringing user centered design practices in to agile projects. I wanted him to enlighten me, show me what I had trouble figuring out on my own while running the UCD practice at a large(ish) software company in the throes of ‘going agile’ - how do traditional UCD techniques integrate into agile methodologies? How do you do holistic interface design within the constraints of a short sprint focused on microfeatures? How do you squeeze effective user testing into the schedule? Where does user research and analysis fit in? How can I leverage the 1:100 rule and make sure my $1 spent on usability will save $100 in support/qa/bug fix costs?

UI13 was great overall. I got to listen to Luke Wroblewski talk about content page design best practices, Kim Goodwin talk about visual design and I got to hear Jared Spool deliver a very compelling keynote address. But I left the Jeff’s seminar somewhat disappointed. He talked about agile development practices, and he talked about user centered design practices, but kind of glossed over how they integrate. When I asked the above questions outright at the end of the day, the answer seemed to be ‘that stuff is done outside of the sprint – get your design work done, then start the development.” Did this mean that UX and Agile are oil and water?

Since joining Rypple, I’ve developed a much clearer understanding of what it means to be ‘agile’. It helps to work with a team that is exceptionally well versed in the methodology. I’ve also spent much more time learning – spending more time understanding Jeff’s thinking on the subject (and many others) by visiting his blog, watching presentations such as Dave Robertson and John Johnston from Thoughworks‘ talk on Agile Methods and User Centered Design, and listening to various relevant podcasts on my longer-than-neccessary commute.

So what have I learned? UX practices have always embodied the core principles of agile – user driven, iterative, and reliant on constant refactoring to drive up quality. But in traditional waterfall processes (as well as in large(ish)-now-in-the-throes-of-going-agile software shops), UX work precedes development because the cost of change further down the line is too great – the old $1:$100 rule. You’ve got to get it right up front if you want to avoid costly and lengthy changes down the line.

But it was this dogma that was at the center of my confusion. In a truly agile process, change is expected and embraced and the cost of refinement is not prohibitive. Furthermore, the latency – the time it takes for necessary fixes to be implemented and available to a user faced with a usability gaffe that slipped through the cracks – is minimal. The rationale for upfront UX begins to break down. Believe me, as a guy who wrote a Ph.D. thesis that formalized a ‘traditional’ UCD approach to software design, that is a tough one to swallow.

So, how do you do UX in an agile shop? To be honest, I’m still figuring that out. Here’s what I’ve learned so far: in a truly agile shop, refactoring happens so frequently and so fast that you can afford to (in many cases have no choice but to) treat your production interface as your testing prototype. This means get over the conceit that you can figure it all out beforehand through thorough and thoughtful design, or identify and fix the issues in the privacy of your usability lab. You do not have the luxury. Do your best in the time you’ve got, kick something out, then pay attention. You’ll need the means to learn about real usage – analytics and instrumentation to gather usage data, and a process to identify and reach out to ‘power users’ and newbies alike to gather their thoughts along the way. Then lick your wounds, go back and fix the mistakes you made and get on with making new ones. Fail faster. Learn faster.

Improve faster.

What are your thoughts? I’ll be iterating on mine over the next few weeks, and posting any new revelations here. So stay tuned. Think I’ve got it wrong? Let me know, and (maybe) I’ll refactor. I know I’ll be OK with that.