Agile Project Planning

ExtremePlanner: Agile Project Management for Distributed Software Teams
Click For Your Free Online Trial

Saturday, July 30, 2005

Can user interface design be agile?

The core principles of agile development focus on rapid feedback, frequent releases, and a close relationship with the customer. But many developers of enterprise systems spend most of their time working on back-end infrastructure and architecture that their customers will never see. Certainly non-visual functionality can work well in an agile approach where the customer specifies the "what" but not the "how", but how does this play out for user interfaces?

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:

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams


  • I am so happy to see an article like this one written. Thanx! As one of the founders of IxDG (The Interaction Design Group), many of our members struggle to find a balance to meet the needs of an agile development environment.

    one issue you didn't bring up is the who. Who should be getting the feedback. Experience has shown that while this isn't an absolute, there is something to be said to have someone in the design role who has specialized skills including:
    * ability to empathize
    * knowledge of HCI material
    * ability to create pattern languages (from a UI perspective)
    * and many more.

    My point is that while your article very rightly says that we need to do the work of IxD, it doesn't go so far as to say that there are different roles and bodies needed to get this work done.

    While About Face is a great resource to begin with, another book that deals more directly w/ the "fun" factor you speak of is Don Norman's book called "Emotional Design".

    Interaction Design Group is at and there is a resource library is at

    thanx again for the article.

    By Blogger Dave, at 11:53 AM  

  • I enjoyed this blog. I see that it was written a few years ago, but is still a timely issue as Agile has gained so much momentum and I sense that the place for UI designers is still a bit unclear for some. I recently wrote a blog on The Case for UI Designers on Agile Projects. Beyond the usability and fun, I feel that they add so much more, such as a cohesive look and feel and risk mitigation. Thanks again for your blog. Cheers!

    By Blogger aaron s, at 10:19 PM  

Post a Comment

<< Home