Photo by Daria Nepriakhina 🇺🇦 on Unsplash

They don’t get UX

Lately, senior leaders in product development organizations have been asking me some provocative, “anti-UX” questions like: 

• What is the value of (more) UX? 
• Why do you need empowered teams and triads? Why don’t we use an agency model? 
• Can’t the product managers do the research? (a particular fave of mine) 
• Why can’t the devs implement the design system?
• Do we even need usability testing? (another fave)
• Why bother with user research in discovery? We know our customers. (so good, right?)

Maybe you, too, are asking these questions. If so, you are likely wondering what happened: I thought UX was supposed to result in great products, so why are customers still complaining about usability? 

If you are on the receiving end, you may be at a loss to answer because there is plenty of evidence that UX results in great products. But you and your team keep hitting these roadblocks (not enough time, too little research, no voice or agency on the team, etc). And if you’ve been in UX for a while, these questions might make you feel like you’ve time-travelled back to the early 2000s.

Sidebar: Back in the early days of UX, it was a fight for those new to the business to get a seat at the table. Devs were often dismissive, BAs (essentially the equivalent of today’s product manager) were uninterested, and senior business leaders asked, “So what’s the value to me? Why should I spend on UX?” Here we are 20 years later, and senior leaders ask the same value-based questions. 

But there has been a change. I recently worked with a team to look at how they might create a more systematic approach to UX and found that the product development team wants more UX, not less. They have fully embraced the value of the UX perspective and invite it to the table. Further, the team said that when UX is included in the early discovery stage, they see better outcomes, less rework, and more innovation. Their direct experience is that the team can focus on innovation with less time spent putting out fires (technical and UX debt, dealing with customer complaints, and reworking what they didn’t get right). 

As common as the “anti-UX” questions from leadership are, so is the high value placed on UX by the on-the-ground teams. I’ve seen it everywhere I’ve worked, consulted, or contracted in the last ten years.

So, what’s going on? Why don’t leaders see UX as essential when those developing the product do? Why are leaders trying to break the empowered team model and minimize UX’s work when product managers, owners, and developers say they depend on it? Many in the UX community respond, “They just don’t get UX. They don’t value design.”

There is a gap between what senior leadership sees and values and what product development teams see and value.

That got me thinking: Is it merely that senior leaders don’t grasp UX? All the explaining and advocacy we’ve been doing for the last 20 years should have dealt with that, no? 

Leadership’s point of view

UX has been a part of product development for a long while. From a leadership perspective, the long-held promise of UX to deliver desirable, usable products has yet to be fully met. While many brilliant digital products are out there, there are likewise many less-than-stellar products. I hear a common frustration from UX people about how the products they are working on could be better. For the leaders of organizations where the products are suffering usability problems and are less than desirable, it’s not a giant leap to question the value of UX. For them, if UX represents desirability, and the product is not desirable, then UX doesn’t deliver. 

And for the UX leaders trying to make the case that UX is necessary, that the spend on UX resources is worth it, and that the perceived “extra” time needed for research will net dividends will find they are painted into a corner. If UX is supposed to make the products desirable and there are customer complaints about usability or if salespeople are coming back with poor sales results because “people just aren’t buying,” they don’t have an argument to make. 

False Premise

Over the last 20 years, the complexity of the products we create with digital technologies has increased exponentially. Back in the beginning of UX, the problems we were designing for were relatively simple, linear problems. How can we make it easy to ‘add to cart’? How can we help people search extensive databases of products? That’s not to say that those problems were trivial or always easy to solve at the time. It’s that the number of dependencies was limited. Today, however, we are designing software and systems that are far more complex. There are multiple dependencies, points of interaction, and possible outcomes. We also aim to look beyond the immediate system into how it impacts large groups of people, responds to changing regulatory environments, and changes in our approach to privacy and security.

The whole argument is based on a false premise. The underlying assumption that senior leaders are making is that product development is a linear process. That UX can entirely “own” the resulting product’s desirability (including usability). That may have been the case once. But today, as we design and build increasingly complex digital products, the outcomes rely on the interaction of and interdependency of each element in the overall system. Viability, feasibility and usability are not stand-alone silos entirely under one person or team’s influence. Each aspect is interdependent on each of the other elements. Constraints beyond the designers’ control heavily influence the usability outcomes. Likewise, the product’s viability and feasibility are influenced by its overall usability. 

The product development process is a system, not a linear process. And that’s the significant change that some leaders need to see. The teams on the ground may not describe product development as a system, but they are feeling it and behaving that way. 

What is a system?

Let’s take a step back. What is a system? A system can be defined as An interdependent group of items, people, or processes working together toward a common purpose. 

Understanding that digital product development is a system is essential because of the nature of systems: systems can’t be valued as the sum of their parts but as the product of the interactions of those parts. Stated differently, asking ‘What is the value of UX?’ is the wrong question. The question is not answerable because UX is a part of a larger system. The better question is, ‘What is the value of the product development team’s output?’ 

To help us understand this view, Dr. Russ Ackoff, an OG of systems theory, gives the car as an example: “The essential property of a car is to take us from one place to another. This is something that only a car as a whole can do. The engine by itself cannot do this. Neither can the wheels, the seats, the frame, and so on.”

So, in product development, does it work like an assembly line where one person works on one thing and then moves on to the next? That may have been the case once. But now, with our digital products’ increasing sophistication and complexity, we solve problems as a team. We may describe stages of the process, such as discovery, design, and development, and we may even have a linear depiction of a process. But anyone who has spent time inside a product development team knows we shift among these stages as we move from the initial concept to the final product. The best teams are not siloed functions but interdependent groups of people and processes that work together to produce digital products.

How does this help us make better products?

Going back to the project I was working on with the team wanting a more systematic approach to UX, what I found was that there were five key factors affecting the overall user experience of the end product:

1. More upfront user research is needed in the development phase. To be clear, I mean well-structured, proper user research, not loose ad hoc feedback.
2. Designers and researchers need to be given more time or resources to do the job.
3. Freedom, trust, and time are needed to design rather than merely add colour and form to someone else’s ideas. Again, to be clear, this does not suggest that the designer is not collaborating with the rest of the team. It is about letting the designer lead the design process by leaning into their specialized skill set.
4. There was little to no usability testing, or if there was, the results were minimized or ignored.
5. Business and technical needs were prioritized over user needs.

These are all symptomatic of a linear, assembly line, or feature-factory approach to product development. 

How can we shift to a systems-based approach? (For Senior Leaders)

I get it; it’s a significant shift. If you’re a senior leader, you have to justify spending more on UX when, so far, it seems like UX still hasn’t delivered. Plus, what about the rest of Product Development? Does this mean you have to spend more there?

But you’ve already started making that shift. When you realize that Product Development is a system and UX is no less essential than Product Management or Engineering, you can see what shifts might occur.

In one organization I worked with, once the senior leader saw the systems nature of the product team, she immediately saw how shifting one person’s role to do more discovery research would also pay dividends for the organization at large because they could tackle more of the bigger questions that they hadn’t had time for so far. That person saw how the outputs of discovery research would have a far greater reach and positive impact beyond just the product at hand.

In other places, it may mean supporting the elevation of someone into a UX manager role and growing them into more of a leadership position. That person could advocate for and make space for other UX people to do the necessary deep-focus work.

Listen to the on-the-ground teams. They want more UX for a reason. They know that they are more productive and produce better results as a team when they have UX as an integrated, fully participating partner. You are already there; it just needs some support. So, find ways to lean into a system-based approach and shift from the assembly-line feature-factory thinking. 

Also, this can be done in stages. However, it needs to be approached from a supportive and systems-aware point of view. Stop asking what the value of UX is and start looking at the outputs of your product teams. Stop pushing velocity and deadlines and start a) making space to design and build the right things and b) empowering and trusting your team to deliver what they need to. This is not to say to drop deadlines and not manage the teams but to ensure that you give people enough space and trust to do what they know they need to do.

How do we respond to the “Anti-UX” questions? (For UX and Product leaders)

Even with a systems understanding, UX and product leaders may still need help to take this view to their senior leaders. Here are some thoughts about how to respond to the Anti-UX questions with a systems lens:

What is the value of UX?

UX is like the motor oil in a combustion engine: sure, you can neglect it or try to water it down, but sooner or later, your engine will seize up. If you want the best performance from that car, you need to use quality oil. If you want the best performance from your product development team, you must ensure the UX team is operating at the right level of maturity for your organization. As a rule of thumb, the more complex your product, the higher the level of maturity required.

Why do we need empowered teams?

Product teams are more like surgical teams than they are like assembly lines. You want a team where people will say something is wrong if they feel something is wrong, work together to achieve the best outcome, and fire on all cylinders. You want a team where people deliver their best, lean in, feel safe, and like they belong and have a voice. 

Can’t the product managers do the research? 

Research is more than just “feedback”. It’s a specialized skill that takes time and expertise, especially in the discovery phase. You could do your admin assistant’s job, but why would you? To ensure you deliver value, you need that admin to free up time to do what you’re good at. The same applies to product managers. They are also highly skilled at what they do. Why would you want to load them up with lower-value work (for them)? Why would you want to decrease the productivity of your product managers like that?

Why can’t the devs just implement the design system?

The design system is essentially a set of objects without a plan for how they fit together. The design is a holistic plan that takes into account all of the requirements, user needs, and context of use. Imagine trying to build a complex building like a hospital. Would you ask a builder to build a hospital without a plan? Hospital-to-hospital ERs, ORs and all the other rooms have many of the same characteristics. There is essentially a design system for hospitals. However, it would be unthinkable to ask a builder to “implement the design system called Hospital.” There are many complex questions from site to type of hospital to patient needs to security and technology integration. The same is true for designing complex digital products. 

Do we even need usability testing?

Why would you skip any opportunity to observe how your customers interact with your product? The junk heap of failed products is littered with insufficiently tested products. Again, we’re talking about products with a fair degree of complexity where hundreds, if not thousands, of decisions, trade-offs, and compromises have been made along the way. At the very least, usability testing will tell you what challenges customers will likely encounter. At best, not only is it a fresh opportunity to gather more insights about your customers, but you also begin to arm marketing and sales with fresh insights; you can even start thinking about how you might optimize or even innovate. You begin creating a beautiful, virtuous cycle of insight into innovation. Why would you limit that?

Why bother with user research in discovery? We know our customers.

Taking into account the opportunity to know your users better and that user research is a specialized skill that requires not just talking to people but knowing what research to do, how to do it AND spotting the strategic insights coming out of the research, I would also ask which would you rather do: place a bet on an unknown horse or team based solely on your gut or with the help of an all-knowing genie? Outstanding discovery research is like that all-knowing genie. It opens the door to strategic foresight, to seeing around corners. It’s highly strategic. As such, it is both empowering and powerful. By making product decisions without the benefit of that discovery or strategic UX research, you are making a blind bet concerning your users and how they will respond to your big idea. 

Where are you on a systems-based approach?

Here is a table to help you consider whether your team uses a feature factory or systems-based approach. This is different from saying that every team needs to be fully systems-based. A more systems-based approach is highly beneficial for teams developing products in complex product spaces, including highly regulated spaces or those with multiple stakeholders with differing needs. If your team develops relatively simple products and you get tons of customer feedback about how great your product is, there is no need to change. If not, consider the table below and look for places to shift to a more systems-based approach.

Ping me if you want to discuss systems thinking, systemic design, or how to shift your product development team to a more systems-based approach.