Is Agile Development Killing Usability?
In this article on Wired, the author raves about Apple's attention to detail in something as small as a Date column changing its format when it's resized.
While I was adjusting the width of the columns, I noticed that the date changes format depending on the width of the column. If the column is wide, the date is displayed as "February 27, 2006." But if you narrow the column, the date changes to a shorter format: "Feb 27, 2006." If you narrow the column even further, the date format changes to the shortest format possible: "2/27/06."
In one sense, agile development approaches have nothing to say about this level of usability or "delight", as this is something the customer or "product owner" needs to specify and prioritize. So a customer that values the little details that make users squeal in delight would be wise to consider those as priorities, assuming they aren't too costly.
But in a more philosophical sense, since agile development promotes frequent delivery, and ruthless prioritization, your team will quickly be forced to make choices about what its true goals are. For commercial software, little touches can be critical to building loyal users, but it's the big features that get most of the attention. Internal software will often make do without the bells and whistles in exchange for more features, since their users are somewhat captive.
It does seem, though, that agile teams will be less likely to either prioritize or implement some of the more subtle touches of the kind that the Wired article discusses. When forced to choose between the features "Send email", and "Implement graceful date column resizing", guess which one is likely to get short shrift.
To offset this effect, I think it's important when working on a project to be very clear up front what the team values. If "user delight" is a priority, it needs to become infused into the team psyche. Developers, designers, testers, and the rest of the team need to be aware that any idea that can benefit the user experience is worth writing down for future consideration. Every decision needs to be made in the context of "How will this benefit or detract from the user experience?"
Ultimately it will be the customer/product owner that makes decisions about what should go in the software and when, but with the whole team focused on adding value to the user, many more opportunities for small wins will be uncovered.
Agile development is an ideal way to get quick feedback on these kinds of subtle features with its emphasis on frequent releases. But you may need to guard against the complacency around user experience that's often expressed as "If the user didn't ask for it, they obviously don't need it."
It's our job as software designers and developers to see beyond what is asked for to what is truly needed. And sometimes we have to go beyond need, and find joy.
There's nothing more satisfying to me in the field of software than a truly delighted user. It's hard to put a price on that.
For more on agile tools and techniques: http://www.extremeplanner.com
(Tags: agile, usability, project management)