The product manager and lead engineer were happy when I joined the team. When I talked with them about the study I planned, they seemed interested. We agreed on interviewing 40 people with the goal of identifying user needs and uncovering current product pain points.

The product manager wanted to use the results to help develop a detailed specifications document, which will guide the development team. I planned a study that involved four groups of participants – teenagers, students, high-tech employees, and senior citizens. I prepared a detailed discussion guide, then recruited and scheduled all 40 participants by myself. Some of the study sessions were held in our offices and some at users’ homes. The product manager and lead engineer did not observe or join any of the interviews. I didn’t care so much. I was so excited about this project.

When I was done, I sat down to analyze the huge amounts of data. It took me three weeks to complete, and in the end I proudly published a detailed report complete with screenshots, in-context pictures of users, video highlights, quotes, findings, smart insights, and recommendations.

The results collected dust.

I gave a presentation to the entire team, during which the lead engineer and some other team members argued that my data was flawed and that they thought we should develop things other than what I was suggesting. Someone said something about the users that I interviewed and that they were not the right audience. The product manager just sat there and didn’t say a word. In the following weeks, the product manager published a specification document and the team began developing the product. The document was not based on my study findings and recommendations – far from it. I heard from someone that the product manager interviewed some people, but I had no idea who, how many, or what questions were asked.

I felt really bad. Actually, a more accurate description is that I was very angry. How could they behave like that? How could this happen? Why did they not follow my recommendations? They were acting like typical product managers and engineers, I thought to myself. They just can’t develop empathy toward users. All they care about is what they think.

Takeaways

• Treat any UX research as the team’s research, not yours;
• If they feel it’s theirs as much as you feel it’s yours, you are on the right track;
• Ensure the study either answers specific research questions, or helps cover a team knowledge gap, or helps drive a team decision;
• Have the team decide which participants should be included in the study;
• Schedule the study in a place and time that is convenient for your team.

Share your war stories in the comments below.

Getting Buy-in for UX Research workshop

Tomer Sharon will be giving a a half-day interactive workshop for researchers, designers, and anyone who practices UX research and wants to get more buy-in. The workshops will be held on September 21 at LeanUXDenver and on September 25 at The Web and Beyond.

• Yeah, but this study will delay our launch date;
• Yeah, but we already know what the problems are;
• Yeah, but aren’t our designers suppose to know what people need? They are the experts;
• Yeah, but we can’t learn much from only five participants;
• Yeah, but we just want to launch and see if it sticks. We’ll fix it later;
• Yeah, but we can’t pay that much for this;
• Yeah, but our product managers already do interviews and look at Analytics;
• Yeah, but A/B testing gives us all the answers we need;
• Yeah, but how statistically significant is a study with five participants?
• Yeah, but can’t we run a quick study with internal users instead?
• Yeah, but research sounds so academic;
• Yeah, but Market Research already answered our questions.

(inspired by D’Hertefelt, 2000)

People have trouble persuading stakeholders to conduct UX research to begin with. They have difficulties getting sponsorship and budget for fieldwork. They experience hostility when they try to get their stakeholders to act upon research results.

Many UX research practitioners are frustrated.

I can state that with confidence because I heard it time and again when I conducted research for my book about getting stakeholder buy-in for UX research. I interviewed 30 world renown experts in the UX field as well as two book authors that knew nothing about UX. Chris St. Hilaire from Los Angeles, author of 27 Powers of Persuasion, is a communication consultant who is an expert in negotiation and persuasion. Dr. Guy Winch from New York, author of The Squeaky Wheel, is a psychologist, speaker, stand-up comedian, and an expert in complaint psychology.

I am delighted to share these interviews with you and point out some relevant takeaways about persuading UX research stakeholders and about complaining that nobody acts upon research findings and recommendations.

A word about stakeholders. A stakeholder in the UX world is a code name for the people UX practitioners work with. These are our clients, whether internal or external to our organization. These are people that need to believe in what we do, act upon research results, fund and sponsor future research. These could be product managers, software engineers, upper management, marketers, and others.

What are some effective persuasion techniques UX research practitioners can use tomorrow morning?

Here is the interview with Chris St. Hilaire. This is a fascinating piece, 11-minutes long (published with permission):

The primary takeaways from the interview with Chris are:

1. Persuasion is the creation of consensus from conflict or indifference. When done appropriately, persuasion can move mountains.
2. Get over your ego issues. When people say no to research or to research results, it is a sign for you that you should learn the art and craft of persuasion. Anyone can do it.
3. Understanding your audience is fundamental to any persuasion situation. Understand the group you are presenting to. Before you can persuade you have to get people to listen. Make them listen by recognizing stakeholders’ predispositions.
4. Take the “buts” out of your sentences. Use “and” and “also” instead. “Your idea is great. I also think this other idea is excellent.”
5. Use the power of silence. To get people’s true thoughts and opinions, stay quiet. Silence is powerful. It establishes you as a leader and gets you to the truth.

How can UX research practitioners complain effectively?

Watch the 6-minute interview about complaint psychology with Guy Winch (published with permission):

The primary takeaways from the interview with Guy are:

1. UX researchers complain to one another about their stakeholders because they are frustrated and not sure what they can do when stakeholders to not act upon or buy into research.
2. UX researchers should complain to people who can actually do something about the situation. Otherwise, they will become more frustrated.
3. Figure out why previous complaints did not work. Address those reasons in your next complaint.
4. A complaint sandwich is a technique to come up with effective complaints. Basically, it means you sandwich your complaint (the meaty part of the sandwich) between two positive statements (the bread). The sandwich prevents the other person from becoming defensive.

Complain effectively, persuade continuously

Rather than venting and complaining, UXers who are experiencing some challenges with their stakeholders and clients, should tunnel their energy into effective persuasion. Reaching agreement among stakeholders establishes you as a leader. Refrain from complaining to other UXers. Use the sandwich. Move mountains.