Skip to main content
When research says 'this doesn't work': how to communicate uncomfortable truths in UX

When research says 'this doesn't work': how to communicate uncomfortable truths in UX

By Paulina Contreras•
UX Research

Table of Contents

  1. The role nobody tells you about
  2. My first time delivering bad news (in bootcamp)
  3. The myth of the UXer who only brings good news
  4. “It’s not me saying it, the research says it”
  5. How to communicate a painful finding (without getting killed)
  6. The silence in the room: when we present uncomfortable truths to managers
  7. And if they still don’t listen to you
  8. References

The role nobody tells you about

Since I started in UX, I’ve had to deliver uncomfortable truths. And I’m increasingly convinced that this IS an essential part of the role.

It’s not something they tell you in courses. They talk about methodologies, interviews, testing, how to build a journey map. But nobody prepares you for the moment when you have to stand in front of a team—or worse, in front of managers—and say: “The data shows this isn’t going to work.”

And yet, that’s where the real value of what we do lies. Because anyone can confirm what the team already wanted to hear. But it takes something else to say what nobody wants to hear.

My first time delivering bad news (in bootcamp)

The first time it happened to me was during bootcamp, and I had a terrible time.

The client was an NGO in Santiago. They arrived with the solution already defined: they wanted an app to communicate with their beneficiaries. They didn’t arrive with the pain point, they arrived with what they wanted to build. And we—inexperienced—started assuming THAT was what was needed.

(Today as a consultant, this is something I would work on from the start: why an app? what problem does it seek to solve? But well, clients don’t have to know that, and we were learning.)

We went to do fieldwork, interviews in the homes of the people the NGO served. And there we understood something uncomfortable: they barely used their phones. I mean, yes they used them, but only for WhatsApp, Facebook, and calls. Nothing more. They didn’t even download new apps.

The conclusion was obvious: it wasn’t worth making an app. What they needed was a communication channel through WhatsApp, something they already knew and used.

But first I had to communicate this to my own development team. And they didn’t want to hear it. They wanted to develop. I remember the stress of that conversation, feeling like I was going against my own team.

Then came the presentation to the client. I defended the idea, explained the users’ reality, their way of functioning. We came in second place. The client wanted an app anyway.

But behind the scenes they told us something that stuck with me: they said our team had been the only one that truly understood the user.

It was great and sad at the same time. Great because it validated that we were right. Sad because they still wanted the app, despite understanding that they probably weren’t going to use it.

Over time I think I would have acted a bit differently. First, I would have questioned the initial premise: why an app? what’s the real problem you want to solve? And then, even though I still would have said that users aren’t going to use a new app, maybe I would have proposed something that simulated the WhatsApp experience, something simple and familiar. Arrive with something for the client without betraying what we discovered.

But what I wouldn’t change is having stayed true to what the research showed. That pride in defending an unpopular idea because the data backed it up… that’s still part of what motivates me in this work.

The myth of the UXer who only brings good news

There’s a fantasy in some organizations: that research is basically validating what the team already wanted to do.

“Let’s do a test to confirm we’re on the right track.” “Let’s interview users so they tell us they like it.” As if research were a formality to feel good about decisions already made.

But that’s not research. That’s seeking confirmation.

The value of UX Research isn’t in saying what others want to hear. It’s in reducing the risk of making bad decisions.

Real research can tell you things you don’t want to hear:

  • That your idea doesn’t solve the problem you think it solves
  • That users don’t understand your product
  • That the competition is doing it better
  • That the feature they want to build doesn’t make sense to anyone

And when that happens, the UX Researcher’s role isn’t to soften the message until it’s digestible. It’s to communicate what’s there, with the data that backs it up.

“It’s not me saying it, the research says it”

This phrase has saved me many times.

Because when you communicate something uncomfortable, it’s easy for them to take it personally. For them to feel like you’re criticizing their idea, their work, their judgment. And then everyone gets defensive.

But if you manage to emotionally separate yourself from the message, the dynamic changes. You’re the messenger, not the author. The data is what speaks.

“The research shows that 7 out of 8 users didn’t complete the flow.”

“In the interviews, customers repeatedly mentioned they prefer X over Y.”

“The benchmark indicates that competitors solve this in a way our users value more.”

It’s not your opinion against theirs. It’s data. Evidence. And that’s harder to ignore (although some still try, but we’ll get to that).

How to communicate a painful finding (without getting killed)

After several years doing this, I’ve learned some things that help:

1. Prepare (much more than you think necessary)

A large part of the UXR’s work is preparing the presentation document. And I’m not just talking about “making the slides.” I’m talking about:

  • Reviewing to ensure there are no errors (or as few as possible). If I’m not sure about something or don’t have clear evidence, I remove it.
  • Preparing verbatim quotes and brief videos from users. This is key: when a manager hears directly from the user’s mouth “I don’t understand this,” it’s much more powerful than when you say it.
  • In complex projects, preparing a base of questions they might ask me (yes, like I’m in school 😅). This way I have prepared answers to potential challenges.

This last one has saved me several times. When someone asks “but did you test with users from X segment?” and I can confidently answer “yes, we had 3 of that profile and they showed the same pattern,” the conversation changes.

2. Arrive with data, not opinions

“I think this isn’t going to work” is very different from “80% of users abandoned at this point in the flow.”

The first is an opinion that can be debated. The second is a fact that needs to be explained.

3. Show the risk of continuing

It’s not enough to say “this doesn’t work.” You have to show what happens if we move forward:

  • How much money could be lost?
  • What metrics will be affected?
  • What will happen to the user experience?

Stakeholders make decisions based on risk. If you show them the concrete risk, it’s easier for them to reconsider.

4. Don’t arrive only with the problem: offer solution paths

This is probably the most important part. I never arrive at a presentation only with the pain. What I do is:

First, clearly identify the problem. What we found, what hurts, what doesn’t work.

Parallel or at the end of the document, the solution proposal. Not just “this is wrong,” but “this is wrong and this is how we could solve it.”

Sometimes the problem is small and the solution is direct. But sometimes it’s complex and requires several ways to continue and iterate. Depending on what’s being researched, the pain can be in the experience, in the content, in the flow, in the information architecture… and each has different paths.

What I present usually looks like this:

Finding: Users can’t find X.

Ideal proposal: Redesign the information architecture of the entire module.

Alternative if there are budget/time constraints: Improve labeling and add a direct access from the home.

Next step if we need more information: Specifically research users’ mental model regarding the current categorization.

Sometimes due to budget, the ideal solution isn’t possible. That’s okay. But I point out what the ideal would be, and offer alternatives that fit reality. That gives the stakeholder options, not a dead end.

And sometimes the recommendation is “continue researching something more specific.” Because not every research project answers everything. Sometimes it opens new questions worth exploring before investing in development.

5. Be executive

Managers don’t have time for 50 slides. Get to the point. Main findings first, supporting evidence after.

The silence in the room: when we present uncomfortable truths to managers

Moment of silence in meeting room after presenting difficult UX research findings

One of the most intense experiences I had was at Sodimac.

The objective was broad: understand why another retailer was gaining so much commercial space. It wasn’t “validate our proposal” or “confirm we’re on track.” It was to go find the truth, even if it hurt.

We did a deep benchmark. Not just desk research, we also interviewed customers. And we understood a lot of painful truths about why this competitor was gaining ground over Sodimac at that time.

We presented the findings to managers. It was super difficult. We were afraid to say that they were beating us, and why. These are painful things to hear.

I remember the silence in the room after showing some findings. That uncomfortable moment where nobody knows what to say.

But at the same time, I think we gained enormous credibility. They believed in our work a lot at that company, more than at others where I’ve been. And I think part of that was because we didn’t tell them what they wanted to hear. We told them what they needed to know.

And if they still don’t listen to you

This also happens. And it’s okay.

We don’t have control over final decisions. Our role is to reduce the risk of making mistakes, not eliminate it. We can show the evidence, explain the implications, propose alternatives. But in the end, the decision belongs to others.

Sometimes they’ll ignore your findings. They’ll move forward with the original idea. They’ll build the feature that the data says won’t work.

And when that happens, it’s not your failure. You did your job: you brought the information. What they do with it is out of your control.

What’s important is that it’s documented. That somewhere there’s a record of “the research showed X, we decided to do Y.” Not to say “I told you so” later (although sometimes you want to), but so the organization can learn from its decisions.

Comfort in discomfort (very zen)

Delivering uncomfortable truths is uncomfortable. There’s no way to make it easy.

But it’s what makes us useful. Anyone can confirm what the team already wanted to do. It takes something else to stand up and say “the data shows this isn’t going to work, and here’s the evidence.”

That’s an essential part of the role. And even though sometimes they don’t listen, even though sometimes the client still wants the app that nobody will use, there’s something valuable in staying true to what the research shows.

Because in the end, it’s not you saying it. The research says it.

Have you had to communicate uncomfortable findings? I’d love to hear your experience. Write to me on LinkedIn.

Frequently Asked Questions About Communicating Negative Findings

How to communicate negative findings without generating resistance?

The key is to separate yourself from the message: you’re the messenger, not the author. Present the data objectively, show the risk of not acting, and always offer alternatives or solution paths. It’s not about winning an argument, but about giving the team the information they need to make better decisions.

What do I do if stakeholders ignore my research findings?

First, make sure the communication format is appropriate for that audience (some need numbers, others visuals, others prototypes). If they still don’t act, document the findings and recommendations. You don’t have control over final decisions, but you do have control over leaving a record of what the research showed.

Is it my responsibility as a UX Researcher to propose solutions?

It depends on the context. I’ve seen it varies a lot depending on the company and how the team is organized. In small teams, sometimes you have to arrive with quite elaborate solutions. In larger teams, you join the extended team to work on solutions and iterate on them together. But in all cases, you’re expected to at least point out possible paths: from a concrete recommendation to suggesting that more research is needed in a specific area.

How do I gain credibility so they listen when I bring bad news?

Credibility is built by being consistent: when you say something works, it works. When you say something doesn’t work, it doesn’t work. Over time, the team learns to trust your judgment precisely because you don’t just tell them what they want to hear.

References

  • Portigal, S. (2013). Interviewing Users: How to Uncover Compelling Insights. Rosenfeld Media.
  • Greever, T. (2015). Articulating Design Decisions: Communicate with Stakeholders, Keep Your Sanity, and Deliver the Best User Experience. O’Reilly Media.
  • Minto, B. (1987). The Pyramid Principle: Logic in Writing and Thinking. Pearson Education.
  • Nielsen Norman Group. (2018). Making Usability Findings Actionable.

Related Articles