The Confluence of UXD and Agile

Dietrich Kappe, Thursday, December 20, 2007 @ 11:18 am

User experience design is integrated into software development and other forms of application development in order to inform feature requirements and interaction plans based upon the user's goals. The benefits associated to integrating these design principles include:

• Reducing excessive features which miss the needs of the user
• Improving the overall usability of the system
• Expediting design and development through detailed and properly conceived guidelines
• Incorporating business and marketing goals while catering to the user

--Wikipedia

Consultants lie. They tell you that software X can be developed in time Y for cost Z. That is a lie, plain and simple. The consultant has developed software before, and you know your business, but the two of you have never developed this particular piece of software before, otherwise you would be using it now instead of developing it. So, by definition, in software development you are doing something for the first time, otherwise you would be performing system integration.

This may explain why study after study finds that Software Engineering is notoriously poor at estimating, and why software projects typically run over in terms of cost and time. Enter Agile. Agile doesn't so much eliminate risk as admit that it is there. You don't bother putting together a 24 month project plan because you realize that:

1. The estimate will be off my 400% or more.
2. The client thinks they know what they want, but really doesn't.
3. You'll know way more and make better estimates after 3 months of working on the project.

The core principal that underlies Agile is the feedback loop. You have
short iterations because you want to change what happens in iteration
n+1 based on what happened in iteration n. You do TDD and continuous
integration so that your changes feed back resulting errors. You
perform usability, regression and performance testing so that you can
continuously improve those aspects of the software. You constantly
reevaluate the functionality of the system to make sure it makes
business sense.

In order to deliver functional software in short
iterations, you need to chop the functionality into little bits. One
drawback of this focus on small chunks of functionality is that you
lose sight of the forest for the trees. What makes sense in terms of
one feature doesn't make sense when you string all of these features
together to meet a specific user goal. My favorite example of the
moment is an open source job candidate tracking system we use. A
typical use would involve a hiring manager stepping through all of the
candidates in a job pipeline and determining whether to bring a
candidate in for an interview. A typical pipeline will contain 20-30
resumes. In order to view the applicants resume, the hiring manager has
to navigate from the job pipeline page to the candidate page, look at
the resume, navigate back to the pipeline page, and rate and comment on
the candidate. What should take 30 minutes can take upwards of an hour
and a half because of the clicking and page loads.

All the
features are there, mind you. I can view, rate, etc., but they don't
work well to help me with my goal. If the developers of this software
had used some basic UXD principles, i.e. there is more than just a
"user" of the system, but several personas -- hiring manager,
recruiter, interviewer, project lead -- that each have different goals
and task flows, and will make use of the features in different ways,
then the resulting software might satisfy our needs better.

Using
UXD in an Agile context isn't trivial, however. By it's very nature,
UXD takes the big picture view, i.e. where does this feature fit into
various task flows for different personas? As the iterations progress,
the UX designer has to sometimes rework a conceptual representation of
the entire application -- not an easy proposition if you are working in
1 or 2 week sprints. The consequences can sometimes be painful for the
development team, as well. For example, a newly discovered persona or a
change in a goal or task flow can force the refactoring of perfectly
good features that you thought were "in the can." Still, you can't
argue with the end result: rapid delivery of quality software that
works and satisfies the client's and user's needs.

If you are an
Agile shop or considering shifting to an Agile method (remember,
"methodology" is the study of methods), I urge you to add UXD to the
mix.

Technorati Tags: uxd, agile

agile ajax

Comments: 1 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   Nice way to say the things. I never thought about it that way but it seems quite true to me!

   I like your blog. First time here but many interesting things
   have a good day,

   Comment by Gabriel, Sunday, December 23, 2007 @ 9:02 am

Leave a comment