The Problem (And Solution) with Agile Development and User Experience Design

By: Marc Humpert

As Agile Development methods mature and processes become more firmly in-place at companies everywhere, the role of User Experience Design must adapt and become more nimble. Fortunately these qualities are inherent in the UX Design process and a must with any successful User Experience Designer.

For those working professionals that may be tight on time and perhaps feeling the crunch of the recent explosion of interest in the UX field, this is an excellent article that deconstructs a lot of the buzz around User Experience Design:

As the author Whitney Hess points out, her goal in writing the article was to address the very trend that she contributed to – Hess had given talks before on how “You Are An Experience Designer” and wanted to swing the pendulum back from a possibly self-aggrandizing view of the capabilities of a UX Designer to a more centric balance for the community discussion of UX.

I love Hess’s article for this reason because it demonstrates a heightened awareness of the UX industry and how important it is to remain grounded in approaching it. It has definitely become a hot topic and career field, thanks in huge part to Apple (original Apple alumnus Don Norman is frequently credited as coming up with the term Experience Design). It also, per Norman’s intention, is a term that covers a broad area of knowledge and therefore it opens the field up to a lot of people to operate as User Experience Designers when they are not. That is precisely the nail that Hess hits firmly on the head with this brilliant article.

While cautionary for the field of User Experience Design, it’s a great checklist for bona fide User Experience Designers to run through while doing their work.

One takeaway really stuck out to me and it was from points 1 and 5 where Hess respectively mentions: “If you design entirely based on intuition without ever gathering intel from a single human being who might at some point in their life come into contact with your business, I’m sorry, but you just aren’t a user experience designer” and “No user experience designer works alone… Even a UX team of one relies on stakeholders, visual designers, developers, marketers, the guy in the next cubicle.”

The emphasis on gathering intel from AT LEAST “a single human being” or “the guy in the next cubicle” held dual importance – first in that it emphasized the need for User Experience Designers to TEST their designs with ACTUAL users. But it also brought light to the very real issue that User Experience Designers face with Agile Development.

With Agile methodologies operating on short blocks of time in rapid sprints, the first thing to go in the UX Design process is the analysis/testing and verification. In order to keep up with the constant flow and demand of iterations, features, and design specifications from developers, the User Experience Designer (typically one per company) is having to spend all of their time generating mockups and prototypes with little analysis/testing and verification.

However, this concern is nothing new. There are a myriad of articles, including from the eponymous Nielsen Norman group, that engage the idea  of “Lean UX” or the “UX Team of One”. Leah Buley gave an excellent talk about this at the 2009 User Interface Conference:

And 2009 SXSW Festival/Conference:

What I found so comforting about Hess’s article in particular though was that she engages the idea that hey – a time-crunched UX Designer might HAVE to turn to “a single human being” or “the guy in the next cubicle” for testing. And honestly, that’s ok because, while it’s the bare minimum, it’s better than nothing.

Jakob Nielsen engaged this idea back in the late 80’s with his paper “Usability Engineering at a Discount” (back when User Experience Design was still referred to as Human Computer Interaction). Essentially his paper demonstrated the results of a quantitative study that in teams of 3-100 people running usability tests, the usability problems returned were not significantly higher in the larger test groups of 100 than with the smaller test groups of 3.

While this may not be ideal, it’s still something.

So whether you call it “Discount Usability”, “Lean UX”, or “UX Team of One”, Hess is right that someone – anyone – participating in a usability test in collaboration with the User Experience Designer is better than nothing, and still effective.

But what about Agile Development? Is this enough to survive a process that seems to inherently cut short the time available to develop a solid User Experience Strategy?

Agile works well for programmers – it effectively gives them an opportunity to participate in iteration cycles. But it can be taken a step further with teamwork, similar to project-based learning models:

While a whole other topic into itself – project-based learning models are all about collaborative teams working on the same project. Having programmers in an Agile model work with Experience Designers, Product Managers, etc. in small teams increases the level of buy-in to ideas and naturally facilitates the ownership of everyone in the group to the values of User Experience Design. It is hard for an Experience Designer to work alone, promoting the ideals by themselves. But in teams, when everyone is directly responsible to EACH OTHER for the output, a greater level of care is put into ensuring what is done is done right.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s