Issues with Agile, UX and How We Talk About It

As a UX designer, I’ve been working in agile development environments for almost 4 years. I know that might seem like a long time since agile still feels new, but I had a great learning opportunity when I was introduced to it back in 2007. At that time, I, as well as other UXers in the company, were constantly trying to understand, practice and tweak the ways that UX was a part of the “system”. I found my experience to be hugely rewarding and I would recommend the approach that we took to almost anyone.

These days we’re pretty lucky in that there are a lot more people doing agile and doing it well. We have groups such as the Agile Experience Design meetup that bring speakers and presenters in to talk through the methods and tools that make them successful. This has been a big win for experience design as well as the agile movement overall.

Over time I have been to this meetup and other meetups and discussions around the topic. The speakers are usually very knowledgeable and do a great job laying out the tools that one needs and the things one can do to find success in their agile systems. I have, however, noticed a trend in these discussions. Overall, no matter what meetup I’m at, or what knowledgeable expert I’m talking to, I consistently hear the same line. That being something along the lines of “Here are the tools you can use in Agile and you’ll need to determine what scenarios call for which tools. Sometimes you use this and sometimes you use that. Agile is flexible, yadda yadda.” Ok, I get it, and I agree. But I feel like there is a big gap in knowledge here. How does one determine what tools go with what scenarios? More simply, how do I know what tools to use when…. and how do I make the right decisions for using them. What is the process of determining the right tools?

In these discussions, it seems like we are just supposed to know. For example, here is a new deliverable called a half-wireframe-half-sketch-half-documentation-thingy-guy. You might need it, you might not… it all depends… then we move on to the next topic. I’m going to argue that in order for UXers to become completely comfortable with this methodology we need to talk more like “here is a new deliverable called a half-wireframe-half-sketch-half-documentation-thingy-guy. You use it in scenarios when there is a need to quickly and visually document the interaction, but not a need to capture the visual treatments at this time. You will also need it when you are passing along the work to offshore developers and testers. I wouldn’t necessarily recommend it for executive sponsor sign off, but if you find that your sponsor does bla bla bla go for it. and etc”.

This now turns the information into usable and digestible pieces. Here is the theory, here is how we apply the theory. Basically talking in this regard allows the listener to embrace the tool and empowers them to use it to the best ability. Now, I’m not calling for hard fast rules here. I get, and love that agile is ever changing and flexible. But by establishing some sort of knowledge transfer when we talk about our successes we are providing a foundation for others from which they can create their own flexibility of tools and processes.

So, in short… can we please change this discussion? The next time you get up to speak about or go to listen to an agile and UX talk, talk about how we actually use these tools and more importantly how we go about making the determinations for use. This will allow us to pick up our pace when it comes to this newer system and help us to better integrate with our development partners… thus leading to products that more closely follow our designs and are ultimately better for our users.