Agile UI Development: What's the User Experience?

Posted by Deborah Hartmann Preuss on Feb 19, 2007

Sections

Process & Practices,

Architecture & Design

Topics

Agile ,

Customers & Requirements ,

Delivering Quality

Tags

Complementary Practices ,

Useability

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?

1. Back to top

   UEX is like Architecture (in some ways)

   by Paul Oldfield

   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)?

   Reply

2. Back to top

   Paper Prototyping URL

   by Chris Gardner

   The link to Paper Prototyping needs to be changed from:
   
   www.paperprototypig.com/
   
   to
   
   www.paperprototyping.com/

   Reply

3. Back to top

   Agile Usability on Yahoo! Groups

   by Dean Morrow

   If you are interested in the merging of agile and UX, check out the Yahoo! group Agile-Usability at tech.groups.yahoo.com/group/agile-usability/

   Reply

4. Back to top

   Re: UEX is like Architecture (in some ways)

   by Dave Churchville

   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).

   Reply

5. Back to top

   Agile Prototyping Resource

   by Franco Martinig

   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.
   
   www.methodsandtools.com/archive/archive.php?id=17

   Reply

6. Back to top

   A couple of cautions

   by Carl Sgamboti

   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.

   Reply

7. Back to top

   Article Link

   by Joe Johnson

   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.

   Reply

• Older >