This is likely a familiar story: Your team has spent weeks defining the UX for the latest site, app, or software project. Together, you’ve carefully considered the business requirements, engaged with users and project leaders, planned out UX strategy and interactions. It’s time to show progress to your stakeholders, internal clients, external partners, or whoever has skin in the game.

A request comes back for a change to the interface. It seems reasonable enough on the surface, but it’s one of those requests that has serious implications for the site or app’s experience. Deep in your UX team’s heart, you all know that it’s not the best way to serve the people who will use the site or app.

Even so, you want to say yes to the request. It comes from a stakeholder, dammit. They have political sway and power. You might even feel like you have to say yes.

But you don’t have to say yes. Your responsibility is to determine and communicate what is right for the experience your team is building.

Why Do You Say Yes?

Saying yes is safe. It removes the need for tough decisions, uncomfortable discussions, and volleying of arguments. By simply saying yes, you can make sure that egos remain fully intact and that everyone can come out a winner.

Everyone, that is, except perhaps the people who will actually use the resulting site or app.

Saying yes is easy. In fact, it’s too easy. In many cases, simply saying yes borders on UX negligence.

Your users don’t know about the excellent experience you meant to give them before the internal requests for additions and changes and reorganizing and omissions. They only see the end result, morphed as it may be by a string of “yes” responses to every stakeholder whim.

There are times when you can absolutely, assuredly, without a doubt say yes to your stakeholders’ requests. Doing it too often is how great UX crumbles, through reasonable yet misguided internal requests that make their way into production.

Next time your team gets this kind of UX-changing request, stop right there. Consider the following before you give your answer.

Truths About Stakeholders

Stakeholders, clients, partners – whoever you’re working with to usher a new or improved digital product into the world, these are smart people. They’ve been entrusted with the success of a large site or app project and to make sure that it does the business a world of good. They are laser-focused on improving a bottom line and making it all happen on time and on budget.

These are also the reasons that stakeholders are some of the worst people to weigh in on UX decisions.

Stakeholders are not UX experts.

Stakeholders know when something doesn’t sit right with them, but not necessarily the best way to fix it. Since they are can-do, intelligent people however, they will try to offer a solution. This solution will be based off of their business-focused perspective of the project. It will almost never have anything to do with the UX your team has put in place.

The whole job of being a stakeholder is focusing on internal needs.

Stakeholders, clients, partners, etc. are coming at a project from an internal business perspective. The success of their role in the project means that they have to keeper a laser focus on internal business needs and to be sure that they are met every time.

You’re not doing anyone any favors by pretending to agree.

In fact, you could be tanking the whole project. Without a dissenting UX voice guarding against bad usability decisions, the wrong kind of strategy will go into place with each misguided request. When that happens multiple times, you can end up with a site or app that does everything but serve the people it’s meant to serve.

Failing to recognize these truths about how stakeholders operate and reacting accordingly will lead you to the worst-case result: The site or app flops and your team takes the blame for it. The immediate and temporary ease you gained by saying yes is now worth nothing to anyone.

Not Saying Yes Doesn’t Mean Saying “No”

Just like you should think long and hard before giving a flat out “yes” response, you won’t usually give a straight up “no” either. Your stakeholders are smart, remember? So some kind of valid concern or need is behind their UX nightmare of a request. They need your team’s perspective and guidance to turn their unusable idea into something that works for all parties.

It’s time to turn the request into a discussion.

Understand the concern.

Become the world’s best listener. Ask your stakeholder, client, or partner to walk the UX team through the reasoning behind their request. Your UX team can tell you if there are standard UX answers to the problem that they can recommend implementing instead.

Offer creative solutions.

If there are no standard UX answers to stakeholder requests, your UX team can explore possible solutions that answer both business and UX needs. Can they play with placement, spacing, wording, visuals, etc. to make everyone happy or at least happy enough? Mock up these possible solutions in sketches, wireframes, or prototypes to help stakeholders understand your vision. People respond better to things they can see.

Present evidence.

Sometimes stakeholders assume that since what they have presented is an opinion, that your team’s point of view is an opinion too. Fill them in on how you know what you know. Share anecdotes about times you’ve seen the approach they’re requesting fail, data from user research, truths about how humans behave when interacting with screens, findings from user tests you’ve run where users struggled with a similar concept, or direct evidence from users themselves.

Other Answers That Aren’t Yes

If your team’s best creative thinking, data-based reasoning, and UX answers don’t work, you are going to have to enter that territory of uncomfortable conversation. This is the moment where the temptation to say yes is at its peak. Be strong, take heart, show no fear. Remember that you are trying to save your users a world of hurt.

Sometimes “no” really is the right answer.

Occasionally, in the name of all that is UX, you have to dig your feet in. If you’ve been reasonable on everything else, holding firm should make stakeholders take note that the request really is an issue. Digging in when it’s necessary also gives you unspoken respect as someone who does not give up on important things.

There will be times where you have to give in.

Every once in a while, you will have discussed the request, appealed to UX standards, come up with a creative solution, provided evidence as to why the request is a bad idea, firmly put your foot down and still your stakeholder, client, or partner will not let go of their UX-killer of an idea. At this point, they leave you with only one response, which is “Yes, BUT…”

Even as you say “okay, fine” you should be documenting the reasons that the request is a bad idea for usability. Be kind, as we all get misguided at times, but clearly state why the request will have a negative impact on users and what you anticipate the risk of implementing it will be. Deliver this to your stakeholder, client, or partner as part of your surrender.

When the you-know-what hits the fan months later, you can point to the document (avoiding the phrase “we told you so”) to show what went wrong and how it can be corrected. This way, even in your yessiest moment, you are not offering a simple yes to something your team knows is a bad UX idea.

Save “Yes” for When You Really Mean It

Your stakeholders, clients, and partners are well-intentioned folks who want the site or app to succeed just as much as you do. Their perspective is valuable and will ensure that the product does what the business needs it to do. But they are internally focused, and their thinking often stops there.

It’s up to you and your team to champion users, making the site or app successful in your own way by turning it into something that people don’t want to do without. That means knowing when “yes” just isn’t going to cut it and responding differently.