Mapping Business Value to UX, Part 3
Published: December 9, 2013
The last time you heard from us, in Part 2 of this series, we expanded on the method of mapping business value to User Experience that Lis described in Part 1 and also described how we put that method to work in a real-life workshop. Now, in this third part of our series, we’ll describe the aftermath of that workshop. Our goal is to disclose the findings from our survey and the observations and takeaways from our workshop, as well as some highlights of what we learned about how we, as UX professionals, should consider moving forward in attempting to sell our value to our business and executive partners.
During our workshop’s discussion period, a participant made one very salient statement: “I know that, when I have a member of the UX team on a project, it runs better. The output is better. But, I can’t tell you why.” This kicked off just one of several spirited discussions, which focused on process, value, and communication.
Since the organization for which we conducted the workshop had transitioned its entire development organization to agile, many participants had particular questions about how to incorporate the UX activities we had outlined in our charts into their agile development process. User Experience and Creative Services had previously used an agency waterfall model, and while User Experience was transitioning to agile, Creative Services was not—nor did they have dedicated team members.
Typically, each organization implements agile in their own image, and this has caused a feeling of unease for everyone involved in agile projects. So, of course, this made agile a hot topic during the mapping session. We also saw the “How do I fit User Experience into agile” theme throughout our survey responses. (In true UX fashion, we made sure that everyone filled out a survey before the workshop adjourned, so we could measure the success of the workshop.)
To address the concerns that arose during the workshop, we suggested an approach that involved keeping UX-focused activities, including prototyping and guerrilla usability testing—within two-week sprints, and conducting foundational, cross-product research outside the agile model. Major usability studies and generative user research for products can occur either for an entire release or for an individual epic, complementing the discovery and development tracks.
Once we discussed the thorny issue of process, we moved on to accountability and responsibility. This was not a new problem for this organization. Within the organization, ownership philosophies fell into one of two camps: either one person owned everything or no one owned anything. This false dichotomy led to major questions about the UX activities that we described. Was it up to a team to execute them or a product owner without a UX background? One participant believed that product owners were already doing all of these activities, so wasn’t sure why User Experience should be involved. Needless to say, there was a communication gap.
During our workshop, we demonstrated why these activities are necessary because of the clear business value that they provide, but the question of how to execute them remained unresolved.
What we saw as a result of the workshop was a desire to take decisive action—but at a management and organizational level. The key idea that people took away from the workshop was that user experience is something that everyone owns.
A couple of months after the workshop, the company disbanded the UX team. Overnight, the former members of the UX team transitioned to unicorn status—and became responsible for all UX activities for an individual product. Each of the three most profitable and visible products had a unicorn who was responsible for the product, but the company abandoned large-scale user research and usability testing—particularly cross-product user research. This reflected the statement that we had heard during the workshop that teams run better with UX people, but never addressed the reasons why.
Later still, the company reformed the UX team, but designers remained dedicated to individual product teams, and there were fewer initiatives devoted to strategy and more projects devoted purely to execution.
Because the discussions during our workshop had focused so much on execution and process, the company’s short-term response was to attempt to improve execution, not strategy. This suggests that our workshop participants were simply more interested in how these UX activities would impact their day-to-day work lives rather than how they could bring business value to the organization.
The Long View
This leaves us with our giant takeaway for the long-term: as UX professionals, our communication style needs to change in a big way. We thought that, just by showing people outside of User Experience that more experience-based UX activities clearly bring more business value, their eyes would open wide, and people would be begging for more. But, in reality, UX isn’t there yet. It’s not that people think of User Experience as something that doesn’t add value. Rather, they may not see the state of User Experience as a problem in the first place. The idea that a company has huge gaps in its knowledge about its users or its ability to design better solutions for its users may be something that only we UX professionals can fully appreciate.
For most people, reality is their everyday job. Project managers are thinking about how to make a project stay on time and on budget. Branding is thinking about how to work with executives and IT to ensure a consistent message. Product Management is thinking about how to ship on time. In other words, people tend to see only the problems that are right in front of them—the ones that affect their jobs directly—rather than thinking about how more experienced-based UX activities could help their company to be more successful.
To sell the value of more experience-based UX activities, we need to keep in mind who we are talking to. We may assume that everyone in a company can feel our pain, but instead, we need to rely on our ability to empathize with the pain that our coworkers feel, so we can communicate our value more directly, using language that is meaningful to them! Once we do that, we can work together to figure out not only how User Experience can solve their particular problem, but solve the problem causing their problem, and even the problem behind that.
The good news is that the power is ours. Our eyes are open, and we have insights into how we need to communicate better. We need to realize that people are not going to come to User Experience to get their problems solved. Instead, we, as UX professionals, must recognize and solve the everyday problems our coworkers face before we try to introduce experience-based UX activities to solve broader, mutual problems. Then, and only then, can we extend our work and influence into solving company-wide issues.
For UX professionals, the time is now. It’s time for us to communicate in the right ways to sell the value of more experience-based activities throughout our organizations. We have already begun this journey, and we hope you’ll come along for the ride. In the meantime, let’s start a conversation within the UX community about how we can better sell what we do to those who need it. Let’s learn how to make them want what we know they need.