UX and Agile Development: 2012’s Challenges and Opportunities

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 work.

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 from.

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 understanding.

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 product.

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 designer.

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.

You Might Also Like

• Goal Challenges and Tool Challenges by Jared M. Spool Jared Spool discusses how to design for two types of challenges.
• Prioritizing Opportunities Across the Customer's Experience by Jared M. Spool Jared Spool discusses how service design helps teams get on the same page about the context of their work