Can user interface design be agile?
One of the challenges in UI development is translating a user goal into an intuitive interface that's fun to use. I say that because sometimes software that's easy to use initially, isn't particularly fun to use after you become familiar with it. All of those helpful, cheery animated paper clips and wizards that helped you get started suddenly become like fingernails on a chalkboard. SCREEEEEEECH!
So for a typical agile process, you'd work closely with the customer to develop user stories (requirements), then go off and produce something quickly, and touch base with the customer to see what they think.
Here's the problem - this assumes that they are capable of telling you how to adjust the user interface to better meet their goals. Chances are, they are just representative of the end users, and may not even understand what the best interface is for another class of user. Someone is going to have to make UI design decisions, and our customers might not be the best people to do it. Uh oh.
This problem was recognized by the proponents of Interaction Design, who advocate understanding the different types of users and their goals before producing software that tries to solve it. This flies in the face of most agile thinking, since it does suggest that there is value in designing something up front. Most agile approaches suggest that design is an incremental process, where interaction design (although it certainly can be somewhat iterative), is a bit more concerned with some due diligence and planning to best understand your users.
So who's right?
First, consider that rapid feedback with prototypes is certainly an effective way of communicating with customers, and getting them to engage with the project in a meaningful way. In my own experience, this has been fairly successful, but although you wind up with a useful system, it's not always "fun to use". When I've gone the extra mile and thought of ways to improve the experience by focusing on goals, instead of requirements, I've had delighted users instead of simply satisfied ones.
Why am going on and on about this fun to use stuff? Who cares if it's fun if the system works, meets the customers needs, and is reliable? Well, ongoing research is showing that people are happier and more productive when they use products that are pleasing to the eye and to the senses. Apple's IPod+ITunes combination is an example of a sort of end-to-end "fun to use" product experience. It makes people want to burn and rip music, and even to buy things from the integrated Apple store. It makes them happy.
But still, in a business environment with an enterprise application, do I really care about fun? Actually, yes. It's even more important for people doing repetitive tasks or tedious work to get some joy out the tools they use every day. It's not easy to do, but as developers, if we educate ourselves about what our users need, and look beyond the basic requirements, we're not only making better software, we're actually making our users' lives better.
Being agile doesn't have to mean not listening carefully, taking the time to truly understand what your customer's goals are, and then going off in a whirlwind of activity. Read more about interaction design, and see if it helps you delight your users, and maybe even yourself.
For more on agile tools and techniques: http://www.extremeplanner.com