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.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.
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.
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?
UEX is like Architecture (in some ways)
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
Agile Usability on Yahoo! Groups
Re: UEX is like Architecture (in some ways)
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
A couple of cautions
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.