user experience best practices

Agile is Wrong for UX

Published on June 27, 2012

Wrong – [rawng, rong] adjective – deviating from truth or fact; erroneous: a wrong answer. out of order; awry; amiss: Something is wrong with the machine.

When something is wrong, it deviates from truth or fact. And I can say, with more confidence than ever, that traditional Agile software development methodologies (i.e. Scrum) are wrong for UX. In order to prove my case, I want to take you back to the inception of Agile (as I have read and experienced it) and its related software development methodologies. Along the way, we’ll point out the reasons these methodologies are incompatible with the field of User Experience Design.

The birth of Agile

Agile principles and related methodologies were created for several reasons. Perhaps one of the bigger reasons was in response to the problems of the waterfall software development methodology (the most popular methodology in use up until this point). The waterfall methodology involves defining all system requirements and designs before beginning to build the software. Once these requirements and designs are defined and signed off on, the development team begins to build the software to spec. However, because of its rigid, separate phases, this system proves ill-equipped to handle the changes that can come about as new ideas arise and requirements evolve. This inability to handle change throws off build time and costs in a big way. Thus, the problems of waterfall include high costs in development resources with low return in quality code. Simple put, waterfall proves bad for business.

From this, Agile principles were born. These principles include: 1) a focus on adaptive methodologies, 2) a focus on people and 3) a focus on self-adaptive processes. Different methodologies utilized these principles in order to create working software more rapidly and iteratively to decrease costs and increase quality. And, that is something that Agile methodologies do very well. They enable businesses to make software cheaper and faster, and they also help to incorporate more user feedback in the process. So, why am I saying the methodologies born out of these principles are wrong for UX?

The argument

The second principle of Agile is a focus on people. This must mean that there is a focus on user experience design, right? Wrong. At least, this is wrong for many of the adaptive methodologies that we are putting into practice when we say we are “doing Agile”. Agile methodologies do focus on feedback from users to help create a higher quality and more usable product. However, what you’ll note is that nowhere in the above story of Agile’s birth was any other participant in the software development lifecycle mentioned except for the development team. The focus in creating these agile methodologies was simply on making the development process more efficient. UX was not even an after-thought (It really wasn’t. We had to butt our heads in and keep reminding them that we existed. Nod your head if you agree… Ok, you can stop nodding.) Thus, Agile principles are great, but the adaptive methodologies that employ these principles do not take into consideration anyone else but developers (and stakeholders… someone’s gotta pay for the work, afterall). Furthermore, there is an important reason why these methodologies don’t take anyone else into consideration. Put simply it is because Agile adaptive methodologies are software development methodologies, not product development methodologies. Thus, Agile methodologies were not designed for, nor intended for UX practitioner participation.

To make matters worse, our businesses have latched on to Agile methodologies as a way to decrease costs and increase production. Because of the appeal of saving money, decreasing time and increasing quality, the business hasn’t stopped to really think about how Agile methodologies should be employed, and the effects of employing them incorrectly. The result is that they have confused software development with product development. They are trying to substitute software development methodologies (Agile’s adaptive methodologies) for product development processes in hopes to speed up the entire product development lifecycle. Therefore, the business cuts out any thought of upfront product validation and research, as well as, any product strategy work because these processes are not “part of Agile”. Ultimately, by the business trying to replace product development processes (where UX contributes the most value) with Agile methodologies (which weren’t designed to include UX in the first place), we see UX processes and procedures get pushed out of product development all together (are you pissed off yet?).

Please let us play

In the fury of switching to Agile methodologies, UX does not want to get left behind. Therefore, we keep trying to fit ourselves inside of Agile methodologies (Note: Some companies and startups have found a way to do this very well, but most are still lacking). Most of the time, UX is looking for ways to ensure we are involved, and are thus constantly compromising our processes and beliefs in order to stay relevant. In the process, we lose more and more of the value that we bring and make ourselves more and more irrelevant. We decide that research doesn’t need to be as extensive as we think (and yes, sometimes this is true), and so we cut down on it. We decide that design thinking can be sped up and so we skip through that. Basically we are doing everything to ensure we don’t get kicked off the playground and sent home.

Side note: I do agree that our processes can and should be more lean, and I do see a huge benefit to the appropriate use of Lean UX methodologies. Lean UX is not Agile it’s just good UX applied to appropriate situations, something we as UX designers should be doing anyway.

The solution

Obviously, Agile isn’t going away (for good reason), and UX can’t just stop trying to bring our knowledge to projects. So, how do we solve the issue mentioned above? I think the first step is truly internalizing the issue, that of businesses using Agile methodologies for product development. We need to realize that Agile methodologies are great for software development, but are not great product development.

Second, we need to become educated about the difference between using Agile methodologies for product development versus for software development so that we can educate our businesses to this fact. And, how do we educate our clients and businesses about this? Easy; we tell them how they are wasting their money trying to fit a square peg into a round hole. Businesses have employed agile methodologies to decrease costs (see Learn the Business Behind Our Business for more thoughts on this), but using them incorrectly will only increase costs in the long run. By applying Agile methodologies to product development, something they were not designed for, businesses are dumping money into an investment which will yield a small return. Because they are disregarding upfront research and strategy, they have no idea how their product will sit with users and this is a huge risk (for more info see How to Know When Your Product is Going to Fail). They are also using the wrong resources for the wrong responsibilities at the wrong time, and this is even more costly than returning to waterfall!

Third, we need to design a solution that works, for everyone, and then sell this to our businesses. This might mean a methodology that includes Agile principles in its build methodology (see The Secret Step to Agile: Discovery for initial thoughts. Slides also available), or it might include an entirely different thought all-together. But, we have to have a solution to product development that is cost effective, user effective and tech effective in order to push out Agile as the reigning product development solution. Agile is meant for software, not products…. we have to spread this message.

The aftermath

Once we educate our businesses and help them to see the error in their ways, some important outcomes occur. We get a change in the system of how products are developed that allows UX to exert its value, Tech to exert its value, and Business to be successful. Agile methodologies don’t reign as product development methodologies, but continue to evolve along with their related software development methodologies. This helps to create software cheaper and faster, but also software that is relevant, delightful and useful. But, UX can only get there if we cause a shift in the times, and that shift is the outcome of us changing our ways from people just trying to get invited to the party, to the people who are throwing it. The choice, is ours.

Social Media: Why UX Hates It

Published on June 13, 2012

Social media will save this company! How many times have we heard that one before? We’ve heard phrases like this popping up for a long time now, and, to an extent, I agree with them. After all, social is extremely important, and, if done correctly, can change a company’s path in very positive ways. However, the UX designer in me can’t help but roll my eyes each time I read and hear these statements. I’m willing to bet that many of you UX Designers out there feel the same way, but have you ever stopped to wonder why?

The eye rolling phenomena

Why do we continue to get frustrated when the talk of social media arises? Well, there are many reasons, but the eye rolling catalyst that I want to highlight today is: we are frustrated because we realize that social media is not new, nor has it been new for several thousands of years, and even though we have been saying this for some time, no one has listened to us.

Human beings are social, who didn’t know that one? In fact, UX has been evangelizing the need to be more socially interactive since the beginning of our profession. We study users, we know their behavior, and we know that humans and social interaction go together like peanut butter and jelly! We have brought this up numerous times but have always been battered back with talk about budget, scope, and system constraints.

Thus, the frustration we feel comes from the fact that people today are overlooking UX as the champion of social (Thankfully big names are starting to raise the issue again. See Paul Boag’s Smashing Magazine article Social Media Is A Part of the User Experience for more on that). And, these same people are overlooking UX as the people who can really design good experiences with the social tools and processes that continue to crop up. Instead, our companies look to put into place random social media tools without thinking about how to use them properly in hopes that these tools will save the day.

What This Means

But you see, businesses, putting random tools into place simply isn’t the right approach. One off tool integration is not the answer. The answer lies not too far away from you sitting inside of that UX designer that you hired to use Omnigraffle. It lies in understanding the intrinsic human need to interact and create communities, and, luckily, your UX designer is the one that can help you do just that.  

What this means for UX professionals is that we need to be prepared with the right answers. That means that we need to have a much better understanding of human behavior in order to design social experiences. We can increase our understanding of human behavior through several means.

First, we gain a better overall understanding of psychology. Second, we conduct more ethnographic and behavioral research. If your company doesn’t allow you to do that, figure out how to do so in your day to day life because just knowing more about people will help you gain a better understanding of their behavior.

Third, we stop rolling our eyes at the marketing team (or whomever) when they walk into the room and say we need to be more social (duh!). Instead, we need to educate our clients and organizations about the true value that social provides from an experience standpoint. Then we educate them to the fact that we are the ones that can and should be architecting social solutions based on our knowledge.

What Happens Next

The outcome of UX increasing our knowledge of human behavior and then educating our businesses to our value in the social realm is that we begin to turn the page. We bring the focus of social back to UX as the ones who know about human behavior and the ones who design social media interactions that are effective, profitable, and delightful. We harness our talent to design the experiences that we have been longing to design since we first stepped on the scene, and we prove our immense value to our business partners, thus securing our rightful place as experience innovators.

Social media is ancient. We know this. UX has always known this. But have we explained, in an effective way, how we know this, why it’s important we know this, and what businesses can do with this knowledge? I think not, and thus my challenge to you is to do just that, explain our value in social media in this effective way. From here, let’s see if we can start to turn this tide of whacky buzz terms to a tide of effective UX thinking. The choice is ours.