5 Tips For Overcoming Resistance to User Experience

This article sharing tips to overcome user experience resistance for a more user-friendly corporate culture is written by guest UX author Eric Olive.

A strange thing happened on the way to the bank; the check evaporated.

Here’s what happened. I conducted successful interviews and contextual inquiry (CI) in Latin America as part of a larger user experience (UX) project. After the work was done, the client asked me to complete compliance training online. I agreed unaware of the firm’s resistance to user experience, at least for their employees and contractors.

Round 1: UX Wayback Machine

After logging in and clicking a link to the first course, I saw a list of technical and browser requirements including Internet Explorer (IE) and Netscape Navigator (you read that right, “Netscape Navigator”). Even after adjusting browser settings, nothing worked. So, I called the Help Desk and explained that I was using a Mac.

The tech’s reply? “I don’t know if this training will work on a Mac.” My response (politely): “Isn’t web stuff supposed to be cross-platform?”

The tech’s response: “Well, um I’ve heard of that, but it doesn’t always work out that way.”

“I’ve HEARD of that.” Are you kidding me? The whole point of the web is to disseminate information to as many people as possible.

Round 2: Bad User Experience

Rather than fight the beast, I caved and borrowed a Windows 7 machine to match the client’s version of Windows. Still no go. Once again, I called the Help Desk and spoke to a different technician who asked, “Are you working off-site today?” clearly assuming that I normally worked on site at company headquarters. All of my work for this client was conducted off site.

After the tech’s tinkering, I was able to access the course and even made it to the last module, at which point the screen went blank. I’ll spare you rounds 3 and 4 and simply explain that I gave up the training, the gig, the client, and thus the check. It just wasn’t worth it.

In short, while attentive to a better user and customer experience, there seemed to be a longstanding resistance to user experience for internal-facing systems.

As I realized that something larger was at play, the idea for 5 tips for overcoming resistance to user experience emerged.

The User Experience Lesson

This something larger is the collision of user experience and corporate culture. While the visible problem in the anecdote above is technology, the underlying issue is the corporate culture.

After interacting with this firm over an extended period, the business model is clear. Employees and contractors work on-site 95% of the time with a company-issued asset, their word for a laptop. Understandable and simpler in terms of platforms and equipment. One wonders, however, if this model is sustainable in the 21st century where the best talent and customers are scattered around the globe. These employees and customers not only use a variety of devices and operating systems but also reside in places with vastly varying bandwidth and, in some cases, limited access to reliable power grids.

It’s not clear how well a late 80s or early 90s business model serves these users. It certainly didn’t serve this user.

5 Tips for Overcoming Resistance to User Experience

Following the five steps below will not immediately transform a rigid corporate culture into a lean, user-friendly organization. Over time, however, this approach to user engagement will earn loyal customers and inject a user-centered mindset into your organization.

Tip 1—Crush The Confirmation Bias

The scene: A Conference Room

The attendees: 15 engineers, product managers, and assorted staff

The Purpose: To present results from a usability test of the customer’s product.

Note: UX professionals often conduct lab usability tests to assess the usability (ease-of-use) of a site, app, or product. The moderator (a professional like myself) sits with the participant in the testing room while note takers and observers sit in the observation room. The participant is asked to complete a series of tasks. The moderator explains what to do but not how because the point is to assess how easy or difficult it is for each participant to find information and complete a task.

It began innocently enough, a brief round of introductions as people strolled in to find a seat and space for their lattes and laptops. As always, I remained quiet and listened attentively for signs of concern or discord and, of course, signals pointing to the true influencers (hint: influencers are not always the boss).

All went more or less as expected until we reached the second-to-last person: “Hi, I’m Jim and I LOVE this product!!!” followed by a beaming smile. “Oh crap,” I thought. Few words strike greater terror into the heart of researchers, ethnographers, and user experience experts.

Before the presentation even began the C Monster had reared its ugly head. Yes, the stealthy creature, otherwise known as the confirmation bias, had quickly emerged.

The confirmation bias refers to our tendency to favor information that reinforces our existing beliefs, in this case the engineer’s understandable faith in the wonder of his team’s product. Understandable, but dangerous.

Here’s how it works. When we have a firmly established view about something, say our product, we unconsciously reinforce this view by remembering selectively and gathering information selectively.

It didn’t take long for this engineer and some of his colleagues to challenge my findings, even those that were literally on video.

  • Among the first retorts: “Well, that person hasn’t used our product for very long.” My response was a calm, polite statement about the need to consider new users because there will always be new users. People move, retire, and change jobs.
  • “I’m not sure that’s what really happened. After all, he eventually got through it.” The engineer meant that the usability test participant was eventually able to complete the task. He was right, so I simply responded that time on task is a metric to consider when designing a product and marketing said product to potential buyers.

It was all very cordial, and I was pleased to note that about 2/3 of the attendees were still with me and seemed eager to learn what had happened during the usability test.

One might object that my own biases are at play here, i.e. that I believe in the value of user experience. True, and a reasonable objection. But, here’s the thing. I had already done the work, and I was about to get paid. The client could follow my recommendations, ignore them, or start building picnic benches. The result would have zero impact on my life. So, while I am certainly not bias-free (in the sense of cognitive biases), I had no emotional or financial stake here.

To be fair, this engineer was facing the same challenge we all encounter, our deep aversion to cognitive dissonance, the discomfort we experience when emotions and events do not align with our self-perception and existing worldview. When we feel this discomfort, we tend to re-shape the past and listen selectively in the present. In other words, the confirmation bias is our brain’s way of providing a sense of stability and consistency. While it feels real and comfortable, this sense often skews our perceptions toward the inaccurate.

The solution is to address the confirmation bias head-on. One effective tool is psychologist Gary Klein’s pre-mortem technique. In a pre-mortem, the group tries to anticipate a plan’s weaknesses through mental simulation. Once the simulation is complete, the group looks for ways to counter the weaknesses they have identified. Here’s how it works:

  1. Preparation: Team members take out sheets of paper and relax. They should already be familiar with the plan or design or have it described to them.
  2. Imagine a fiasco: When Klein conducts a pre-mortem, he says he is looking into a crystal ball and seeing that the plan or design has failed. It isn’t a simple failure either. It’s a total, embarrassing, devastating failure. The people on the team are no longer talking to each other. Our company is not talking to the sponsors. Things have gone as wrong as they could. However, we could only afford an inexpensive model of the crystal ball so we cannot make out the reason for the failure. Then, Klein asks, “What could have caused this?”
  3. Generate reasons for failure: The people on the team spend the next three minutes writing down all the reasons why they believe the plan or design failed. Here is where intuition comes in. Each person has a different set of experiences, a different set of scars, and a different mental model to bring to this task. The point is to find out what the collective knowledge in the room can produce.
  4. Consolidate the lists and re-visit the plan or design to consider possible changes.

As Klein explains in Intuition at Work, by starting with the premise that the plan has failed, the pre-mortem technique:

  • Punctures feelings of complacency and a false sense of security.
  • Replaces these feelings with an active search aimed at preventing trouble later on.

This pre-mortem technique not only strengthens the plan currently under consideration but also encourages team members to learn from each other about ways that plans and designs can fail. In so doing, teams become better at mentally simulating how plans and designs are likely to play out. The result is a better plan or product.

By adopting techniques like Klein’s pre-mortem, organizations nurture a more open-minded and empathetic mindset at the individual and collective levels. The result is a more customer-focused culture where an honest assessment of design flaws is not only accepted but encouraged. Eliminating emotion at work is neither possible nor advisable in the sense that harnessing emotion helps us empathize with our customers.

The challenge is to use this emotion to help our customers while avoiding cognitive traps like the confirmation bias.

Klein’s pre-mortem technique helps professionals avoid such traps and, in this sense, acts as preventive medicine.

Tip 2—Conduct Research

If crushing the confirmation bias is preventive medicine, assessing the market’s appetite for a site or mobile app by conducting preliminary customer research is proactive medicine.

This research-based assessment would seem like common sense. Indeed, in a recent Inc. article, author and corporate director Stacy MacNaught explains that the average mobile app costs $270,000 as she poses this question: “You wouldn’t invest $270,000 in developing a product for your customers without doing market research, would you?” (Most Mobile Apps Fail: How to Make Sure Yours Doesn’t). She explains that many companies treat mobile apps differently, as if market research is unnecessary.

MacNaught is right. A few years ago, while teaching a UX design course at a large telecommunications company, I explained the importance of conducting market research before designing a new mobile app because, in some cases, such as filling out long, complex forms, users would be unwilling to use a smartphone. “It doesn’t matter,” replied a student. “Our VP said that everything must be responsive,” meaning that all web sites and apps had to render properly on various tablets and smartphones. There goes another $270,000.dollar

While certainly not sufficient, brief customer surveys are a good place to start if only to gauge whether customers have even the slightest interest in the proposed app.

Tip 3—Observe Your Customers

With preliminary research in hand, the next step is observation. Monitoring calls to the help desk or customer care center is not enough. There simply is no substitute for observing users and customers in a café or cubicle, wherever they will likely use your site or app.

user experience observe users cafeObservation by trained ethnographers and user experience experts is critical for several reasons:

  • Relying on analytics alone will identify a problem but offer little insight into why the problem occurs.
  • Relying on reports from your customer reps (CSRs) is risky because the stress of high call volumes and irate customers (how often do people call just to say “hey, you’re great”?) might not represent the typical user’s experience.
  • Even a seasoned CSR has no training in psychology, ethnography, or contextual inquiry, a method for observing and recording user behavior.

Even one day of observation will yield actionable insights as it did during the first 20 minutes of a contextual inquiry I conducted for a government agency. Employees using a complex web application to process applications for medical assistance needed the applicant’s social security number (SSN) to complete the process. About half of the time, this SSN was not on the paper application. Further, the employees could not use the existing system to search for the applicant’s SSN. Instead, they had to jump through a series of virtual hoops to submit a request for the applicant’s SSN and then wait up to 48 hours for a reply. This delay made it difficult for these already overworked employees to comply with a federal law that required all applications to be fully processed within 30 days.

My colleagues and I identified the problem, re-designed the interface, and worked with I/T to ensure that employees could find the applicant’s SSN if that person was already in the system.

Tip 4—Iterate: Small Tweaks Lead to Big Changes

Just as revising a paper back in college often yielded a better grade, revising a web site or web or mobile app pays. While re-designing the medical assistance web app we revised and refined several times. After each iteration, we paused to conduct usability tests with real users. In the last round, time to completion was reduced by nearly 50%, and the user’s expressed satisfaction was considerably higher than when we began.

While I would love to cite our brilliant design skills as the reason for this success, the truth is that the process works. Your organization can achieve the same results when you build user-centered design iterations into the app development cycle.

Tip 5—Make Micro-Decisions

One way to build iterations into the development cycle is to empower your designers, developers, and product managers to make micro-decisions—a series of choices made by individuals within a specific context they understand and control. Here’s how it works:

  1. After reviewing the most recent customer survey results, a product manager decides to modify one product feature. Not a major overhaul, not a pile of new features, one, small change.
  2. She then passes the request to the design experience lead.
  3. The lead consults with the UX team and development to implement the change.
  4. At this point, the UX team decides how best to evaluate the change before putting it into production.

These micro-decisions could, and should, stem from anyone involved in the product life cycle. An idea for one feature modification could come from the product manager, project manager developer, or user experience consultant. It doesn’t matter as long as the person making the decision understands the context and knows how to move the process forward.

The keys to successful micro-decisions are scale and context. By definition, the decisions are small, highly specific, and made by those who understand the app, the product, the customer, indeed the entire business ecosystem. The decisions are small, purposeful, and customer-centric. As authors Harley manning and Kerry Bodine explain in Outside In:

Great customer experiences don’t happen by accident. They’re the results of countless deliberate decisions made by every single person in your customer experience ecosystem on a daily basis. To align those decisions, employees and partners need a shared vision: a customer experience strategy. Without that beacon, employees are forced to set out on a random walk, and their decisions and actions will inevitably be at odds with each other, despite all best intentions.

Conclusion

By following the tips outlined in this article, you can save random walks for vacations in favor of:

  • Crushing the confirmation bias by actively seeking disconfirming evidence to strengthen your plans and hypotheses.
  • Conducting preliminary research to test the market’s appetite for your site, app, or product.
  • Delving deeply into the customer’s views, actions, and emotions by observing customers in their organic environments from home to café to cubicle, wherever they’ll use your product.
  • Iterating your designs always with an eye toward simplifying the user’s experience.
  • Avoiding stagnation and group think by empowering all team members to make micro-decisions.

By engaging in these activities, you’ll start to overcome resistance to user experience within your organization. With this achievement in hand, you and your colleagues can work toward the long-term goal of establishing an enduring user-centered mindset that seeps its way into the company culture.

What you are producing is important, but gradually overcoming resistance to user experience and adopting a UX culture is far more important than any single site, product, or app. Besides, wouldn’t you rather meet real customers than write another status report?

P.S. Dear Help Desk: Regarding Netscape Navigator. 1997 called; they want their retro back!!!

Leave a comment to let us know your own tips for overcoming resistance to user experience. What have you seen that can have an impact on a more user friendly organizational culture?

About the Author:

Eric Olive is a speaker, teacher, and user experience consultant who:

  • Shows clients how to establish a user experience culture at work and how this culture helps customers and boosts the bottom line.
  • Draws on his testing and fieldwork experience in the U.S., Mexico, and South America as he advises clients about how to conduct market and user-focused research that serves as a basis for culturally intelligent web sites and web and mobile applications.

UX trainer
Eric is the founder of UI UX Training and teaches training on decision making. Learn more about Eric and connect with him online at:

Linkedin: http://bit.ly/2akuLyk

Twitter: @uxcultureworks

Client List: http://uxcultureworks.com/our-clients/

2 Comments

Leave A Response

* Denotes Required Field