Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Agile UI Development: What's the User Experience?

Agile UI Development: What's the User Experience?


When web- and UI- developers first hear about Scrum or XP, they are baffled: what kind of user experience will we get using this iterative approach?  In his InfoQ article Agile User Interface Development, Dave Churchville, founder of ExtremePlanner Software, looks at how teams can beneficially combine Agile software development with another approach that has emerged over the last decade: user-centered design (UCD, also referred to as interaction design). These approaches are lauded by their respective supporters as critical to end user and customer satisfaction, but they seem to be at odds on some key points.

Many Agile projects rely on the ability to "just fix it in the next iteration" as a hedge against making the wrong decision. The idea is to fail quickly while it is still relatively inexpensive. But end users of UI development projects can be intolerant of contant and dramatic changes in the user experience.

On the other hand, user experience disciplines such as interaction design promote a more up-front design process that researches and captures user goals to attempt to optimize software workflow before development begins. This is somewhat in conflict with the Agile approach - this upfront analysis and design can often take several months for a non-trivial project, and user goals may shift as the project unfolds.

Churchville has first hand experience with the business value of good useability:
I remember my first job, where we were creating really sophisticated software that solved problems effectively, but did so in a pretty clunky way.  A few years later, competitors were solving those problems less effectively, but in a streamlined, easy to understand manner, that we just couldn't compete with.  That really opened my eyes to the importance of the whole package - not just the technical superiority of the solution.

I spent the early part of my career building great technical solutions that didn't make customers happy.  I realized that the little things really did matter, not just to make things look good, but to make using the software a pleasure.... Little touches that delight the users, instead of merely satisfying them.

I'm not talking about gold-plating features, but rather looking beyond the customer requests, finding the root of the problem, and designing solutions that  really work for people.  This has to be done in close collaboration with the customer, but you can't expect the customer to always know the best way for you to solve their problem.
Understanding how to really satisfy user goals while simultaneously focusing on delivering frequent and continuous business value is a combination that yields business value by differentiating the resulting product. 

Churchville's InfoQ article Agile User Interface Development explores how the two disciplines can peacefully co-exist. By considering ways to integrate UCD techniques into an Agile project lifecycle, development teams can get the benefits of both approaches.

Related news: User-Centric Development Approaches: What's Next?

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • UEX is like Architecture (in some ways)

    by Paul Oldfield,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I have often treated UEX like Architecture. It benefits from having a single clear vision and somebody to ensure that vision is adhered to throughout. It is best to get it right up front because of the cost of change if we don't get it right up front. People keep looking at it as an example of why we need to do some up-front work.

    Yet like architecture, most of these impediments can be removed and the rest can probably be worked round. Is there any reason why we could not rank requirements by UEX risk much as we do by Architectural risk (or for some teams, much as we did before we were confident we could change as we go)? Is there any reason to believe that UEX will never become as easy to change on the fly as architecture is now (for some teams; apologies to those who haven't got there yet)?

  • Paper Prototyping URL

    by Chris Gardner,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The link to Paper Prototyping needs to be changed from:


  • Agile Usability on Yahoo! Groups

    by Dean Morrow,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    If you are interested in the merging of agile and UX, check out the Yahoo! group Agile-Usability at

  • Re: UEX is like Architecture (in some ways)

    by Dave Churchville,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Paul,

    I agree somewhat with the similarity of Architecture and UX, but I see them as different animals in some important ways.

    While architecture can be "changed on the fly" in a well-kept codebase, user experience isn't as amenable, in my experience.

    Architecture tends to be invisible, and other than performance or scalability issues, does not impact end users.

    Conversely, UX is something that can have a dramatic impact on users, both initially, and whenever it's changed. The cost of change here isn't measured only in developer hours, it's measured in user retraining, impact to productivity, and even in user happiness (more fuzzy).

    So unless you can remove the end-users, I'm still not convinced that UX is something that's a good idea to change on the fly (at least in signficant ways).

  • Agile Prototyping Resource

    by Franco Martinig,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    There is an interesting resource on the same topic: "Agile, Multidisciplinary Teamwork" by Gautam Gosh. It presents techniques and tools used to create requirements with a team composed of the different participants of agile projects.

  • A couple of cautions

    by Carl Sgamboti,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    First, this was an excellent article, Dave. And much needed. Many of us are struggling with trying to find the sweet spot of agile vs. deep analysis. When is our understanding of the problem "good enough"? When do the rewards of moving quickly outweigh the risks of making the wrong design decision?

    Now, on to the cautions...

    Persona creation is not "a quick technique for discovering user goals". User research is the only way to discover user goals. Personas are the end product of user research. Since personas are used to justify design decisions, if they are simply the quick result of a designer/developer's beliefs and assumptions, they will be wrong and we will build the wrong product.

    Is there merit to agile persona creation? Can a persona be iteratively refined? If so, would it be cost-effective considering the ripple-effect (or potential tsunami-effect)? I feel another article coming on...

    And a caution regarding "remote" usability testing with HTML prototypes: This techniques relies on the testers to be able to report, after the fact, on their "impression" of the product's usability. People are invariably horrible at doing that. They misremember, they forget observations, and they are prone to tell you what they think you want to hear. There is no substitute for conducting usability studies in person where the testers' actions and facial expressions tell most if not all of the story.

  • Article Link

    by Joe Johnson,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I hope you don't mind; I'm using this article as a link from my [email] signature job title (Sr UI Developer). This is a great article describing what my position (and many others like it) entail and mean to us.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p