Beta — We’re reformatting our articles to work with the new site, but this is one hasn’t been done yet; it may contain formatting issues. No need to report this. We’re working on it.

UX and Agile Development: 2012’s Challenges and Opportunities

by Jared M. Spool
on February 14, 2012

What started as a whisper in 2001 is now practically a force of nature: change is coming
to the development process everywhere. Folks realized that to produce quality,
competitive software, they had to change the way they approached the problem. Agile
development is no longer a fad — it’s the way people are getting software delivered.

Here we are in 2012 and the Agile wave has now started lapping up on the doorstep of the
UX professional. When our teams move to Agile, it changes how we need to approach our

Our old methods no longer suffice, as they are too bulky and slow for the demands of the
Agile process. Instead we need to come at our work with a renewed introspection of
everything we do.

It would’ve been nice if we’d had a chance to prepare for this, but the shift to the new
development process has taken many by surprise. The result is that we find many teams
working in a very chaotic and frustrating world, similar to trying to change the tires
while the car is still moving, as it were.

We’ve spent the last few months interviewing teams to understand what their biggest
challenges are for this year when shifting their UX practice to an Agile process. While
we’ve been cataloging the challenges, we’ve also uncovered several opportunities that we
think could make us faster and more effective overall, thus living up to the promise of
both Agile and UX: delivering better products.

Agile + UX: A Workflow in Conflict

The biggest irony of the shift to Agile is that it’s exactly what the UX world has been
seeking for years. Yet now that it’s here, we’re wholly unprepared for it.

At the core of Agile is the fast iteration, something we’ve known for decades
produces better designs. When we can experiment with our designs, trying out what we think
will work, then making changes on the parts that don’t, we come to a result that we
couldn’t initially imagine. Agile adds that mindset into the development side of the
equation. We no longer assume that the first build will be the last one.

Yet because we couldn’t have fast development iterations, we filled up our toolbox with
techniques to deliver fully-thought-out designs to the implementors. This left little
wiggle room. And we got good at it.

Now that the tables have turned and the developers are ready to iterate quickly, our
standard toolbox is wholly inadequate for the task. Sure, we can squeeze all of our design
work into the “sprint zero” phase, but that just gets everyone upset because it reinvents
big-design-up-front, something the Agile movement is desperately trying to get us away

Our challenge is to learn what we can about this Agile world and start to adapt to it. We
have to cut up our designs into chunks while ensuring that, when all the pieces fit
together, it feels like a coherent, well-thought out design. Agile doesn’t help us with
this, primarily because it was not conceived with a UX component — we’re on our own for
this one.

The shift to Agile also gives us a big opportunity to explain how we use experience design
to produce delightful results for our users. It doesn’t take more than a few sprints to
see that there is a need for UX in the process.

We can take advantage of the conflict to find a new awareness of our contribution.
Everyone wants their designs to get adopted. They’re all rooting for us to give them the
necessary ingredients to make it happen. When we rise to the opportunity to provide a
clear integration of UX into the Agile process, we end up with a win-win for everyone.

Shifting from Deliverables to Shared Understanding

For years, the UX deliverable was the focus of our work. Whether that deliverable was a
user interface specification, persona descriptions, a set of wireframes, or a UI Style
Guide, everything we did led up to the production of that deliverable. Once we published
it, we could consider our work done here. Then we’d proudly move on to the next project.

Agile teams don’t care for deliverables. The Agile Manifesto values “working software over
detailed documentation” and “responding to change over following a plan.” In an Agile
project, you can’t just drop the deliverables on the table and move on.

If we can’t have our deliverables, what do we do? How will we communicate to the
developers what they are supposed to build? How will they understand who our users are and
what they want?

What many UX teams are learning is that this is a chance to do a total re-thinking of how
we work with developers. Since we’re not dropping a set of documents on their desk, we
have to work with the only repository possible: the developer’s mind.

The opportunity here is for us to re-groove our tools to help developers
understand what we’re all trying to build and who we’re trying to build it for. New UX
approaches, such as Lean UX, do just that. Lean UX takes the best of what we do and
re-appropriates it in a new fashion, away from deliverables and more towards shared

When the entire team has the same understanding of what we’re trying for, the teams work
far more efficiently. They know what the goals are, who the users are, what will work, and
what doesn’t. As the team iterates over the design, trying it out with real users, their
understanding solidifies.

Finally, design isn’t just the province of the designers. Everyone understands what it
takes to create delightful experiences, bringing their own perspective to the table.

The UX Power Tool: Prototyping

Standing in front of a whiteboard, flapping your arms to communicate how you imagine your
design will work, is more like interpretive dance than designing software. Unfortunately,
it’s just about as effective.

The challenge is that, like interpretive dance, the whiteboard discussion is open to
interpretation. That means everyone walks away with a different understanding of what to
build. And that means what gets built doesn’t really match what you intended in the first
place. We had tried to fix this with those huge deliverables, but since they’ve gone away,
many have fallen back to arm flapping.

Enter stage left: the prototype. Traditionally, the prototype has been reserved for
executive demos and, occasionally, user research. It’s mostly been a proof-of-concept
tool, to show what we intend only after we’ve thought it out thoroughly.

Partially, this was because, in olden days, it took a lot of effort to build a working
prototype of our ideas. In fact, it took almost as much work as building the final

In our new, modern world, prototypes are now much easier to build. Armed with the powers
that come from JavaScript and jQuery, the UX professional can render an idea almost as
quickly as they can draw the picture at the whiteboard.

This means prototypes now serve as communication with our teammates, not just with
outsiders. We can build something quick, to show exactly what we mean, and to have a
discussion about whether that’s what we want or not. More importantly, we can change it
fast, letting the prototype evolve right along with our thinking.

This year, we predict that we’ll see a ton more UX professionals prototyping than ever
before. This will become our silver bullet to getting to shared understanding fast. “Want
to know what I’m thinking? Here, let me show you,” will be the war cry of the modern

Moving to Agile is Scary, Until You’ve Done It

On the outset, Agile looks like a foreign new world where all the rules have changed. But
once designers get the hang of it, we’re seeing they really like the new speed and power
that it brings. New ideas are on the table and integrated into the development process.
Innovation moves at lightning speed.

We’ve got some major challenges ahead of us. Yet the opportunities coming this year make
it something we’re really looking forward to.

Share your thoughts with us

What challenges and opportunities are you experiencing as your organization moves to Agile? We always love to hear
from you. Leave us your thoughts at our UIE Brain Sparks blog.

About the Author

Jared M. Spool is the founder of User Interface Engineering. He spends his time working with the research teams at the company and helps clients understand how to solve their design problems. You can follow Jared on Twitter at @jmspool.