Hello! It's wonderful that you're joining us here today. I found your article insightful as I'm dealing with a very similar situation at work. I was wondering if I could ask for some further advice. Here's my story:

I'm currently working on a multi-faceted project, where I have essentially become responsible for all things UI related. This is fine, considering UI/UX was a decent part of my educational background and I have experience from doing UI design on pretty much every team I've ever been a part of. However, what I'm struggling with is constantly being overruled by higher-ranking team members.

I feel like I'm just being dictated to, even for the most minute details. I've tried the "just give them what they want, preserve the relationship" route, but that has just led to a compounding of bad UX. I've tried backing up my decisions/ideas with appeals to textbook UI/UX principles, but that has led to the same polarized arguments you've described in your article.

I have no problem with appealing to rank when a decision is difficult to make. But the issue I have is, when someone pulls rank, they don't bother to explain the reasoning behind their decision. When I try to ask questions to better understand, responses basically boil down to "I just think it looks better this way".

I don't feel respected, despite the extensive background (more than the others when it comes to UI/UX, actually) that I bring to the table, and despite the fact that I'm the only one working on this part of the codebase day-in and day-out. I feel like the ideals of meritocracy are not being honored, and decisions are being made by rank before reason. No one seems open to discussion and understanding. And I'm basically being treated like a junior dev when I'm actually a senior-level engineer.

What should I do?

I was in your shoes at my last job. I tried many techniques for over 2 years, but eventually I had to resign because nothing was going to change no matter what I did.

I was constantly being dictated to or ignored as if I was a Jr. Dev, even though I had by far the most experience on the team. I'm sure I am not the best at handling the nuances of interpersonal communication, so I'm sure I'm somewhat to blame. That being said, what can I do when someone argues against me about something they are truly incorrect about? Just let them carry on and do the wrong thing and further sink our codebase into oblivion? I guess so...

First, talk to HR and their boss. Explain that you are confused about roles; is their role to dictate these decisions? Get clarity on that; is your position expected to be the knowledge asset, or are you just a 'doer', as it were, someone to take orders. If the former, explain that that is not being adhered to, and maintain a dialog with the people you talk to to help get it fixed (HR can work with your boss' boss better define your and your boss' role, to coach them, etc, and possibly, if necessary, reassign your boss or you to a different team, if possible, or let your boss go...or, technically, let you go, though you will almost certainly get an inkling that they do not want to be helpful before you push things to the point they'd feel that step was necessary).

If that does not help, and your role is, de facto or de jure, a brainless 'doer' role, where you're expected to be responsible but not empowered, find a new job.

Seriously.

My wife is in a similar situation. When people make no pretense about the fact that their decisions are based solely out of arrogance (to borrow language from the OP), and their role allows them to do it, and the company sees no problem with allowing a non-knowledgeable resource to make decisions that trump a knowledgeable one, there is no way to fix it from below.

Test your design vs their design with 5 people [1] and share the results with the team. If the results are in your favor, you've effectively elevated the design decision from this sole person to the greater team at large and are then presenting objective data that anyone in opposition of your design would have to publicly admit to colleagues that their reasoning is arbitrary and not grounded in reality.

As a UX champion on your team, you must bring the user's voice to the table and that data will make it easier for people pulling rank to agree with you in my experience, cause they'll never take the time to test designs as they wouldn't have the skillset for UX research whereas you do (or are learning it). Cheers.

1. https://www.nngroup.com/articles/why-you-only-need-to-test-w...

They ignored published best practices (per OP), why do you think they won't also ignore data? "Admit to colleagues" assumes you roped in other managers, do you really think an individual contributor is going to win the political game at that level? Because I've seen what happens at that time; all the other managers nod their heads politely, and then behind closed doors tell the one you were butting head with "You have to reign in your people". All you end up doing is undercutting your entire team's authority, you don't elevate your own above your manager's.

That's a company that isn't going to survive and I'd probably jump ship if they were leaving the product's success to chance and on the whim product decision making. They are in for a rude awakening when competitors leverage full time UX professionals that so the user research to maintain competitive advantage. I agree you shouldn't be brazenly shaming superiors but take a step back and make the data speak for itself.

Hey there! Sorry you're having to deal with this. There's not necessarily one solution or any silver bullet, but there are many things you can try.

The biggest thing I can suggest is to raise your level of thinking from UX to the business metrics. By this I mean, rather than trying to optimize your product for "best UX", try to optimize it for "delivering most value to the customer." Creative people don't like to admit it, but sometimes the creatively optimal thing (good UX/good design/etc) doesn't always imply moving the needle of the business metrics. If you don't believe me, look at how much Amazon sells with their terrible UX. Ultimately the only thing that matters in a business is delivering value to the customer, and if the bad UX doesn't get in the way of that then you can sleep well knowing that your lead's bad UX decision didn't hurt anything.

I've found that thinking in these terms allows me to separate myself and let go of concerns like these. If the poor UX decisions of your manager are having a business impact then you can go find that data and put a dollar amount on it. For example, "I did some A/B tests and we got a 12% lower clickthrough rate with the button there." Your manager may not agree, but at least now you're talking about the customer, not about UX. If you can't produce that data then you still win because the business is unaffected by this mistake and you get to make your lead happy by doing it their way. Winning trust by doing bad UX is still winning trust.

Here's an example-by-story: I was once an engineer tasked with building an automated testing system. Automated tests are easy to understand and so everybody has opinions about how they should work. And so my system's design quickly got bogged down with folks giving the same sort of "i like it better that way" arguments that your lead is giving you. So, rather than engage with any of them, I picked a single battle in the design of my system, something that nobody could argue against, namely that tests should actually be test descriptions, so that the test system can work with declarative data and make decisions about the tests more easily. I showed how that would have a measurable impact on the business (having the test descriptions gives the test system flexibility so we can e.g. filter tests on the fly so that at desk testing times can be kept to a minimum, or easily move tests between BVT and Smoke, or whatever) which sidestepped all of those arguments.

If that doesn't float your boat, I like lostcolony's approach. One possible route of addressing it is to go through the hierarchy. As they mention it can be a tricky approach, you should avoid saying anything negative about your leads or explicitly asking anyone to change their behavior.

You could also try just having an earnest conversation with this person, expressing to them how their behavior makes you feel, and asking them what you should do to gain their trust and the ability to work autonomously. Try to make the conversation not about their behavior, but rather about what actions you can take. "What can I do to take more of these responsibilities on myself?" Then if you hold up your side of the deal, they're more likely to be accommodate you.

It may not be what want to hear, but getting someone else to change their behavior is one of the hardest things you may ever have to do in life and is often impossible. You might have to deal with the fact that this person will always do this. As lostcolony says, you can quit, but I see this as a last resort. You're just going to run into the same problems elsewhere, and it benefits you to learn to deal with the problems where you are.

Good luck!

Jorge

Edit: Looks like sizzle said exactly what I ended up saying but much shorter. And lostcolony's reply to sizzle brings up a good point: You have to present your case delicately, be careful not to make this person look bad, and if they don't respond to hard customer data, maybe it's time to find a team that does.

Hey! Thanks for your article, and thanks for joining the discussion. I think a follow-up article would be great. :)

I'm not sure how much my perspective can be applied to design-related decisions, since I'm a developer. But here are some of the approaches I use as a developer that you may be able to translate into a design domain;

1) Related to your suggestion about having a strong process, I recommend that teams adopt popular coding standards, and then automate the checking of those standards. That way, the nitpicky stuff is the responsibility of zero people, and everyone, at the same time. That helps avoid arguments over inconsequential stuff. Essentially have good, automated QA checking that everyone has agreed to adhere to. In design, that may mean having a dedicated person who enforces things like branding guidelines or solid design principles, I'm not really sure.

2) Related to your suggestion of gathering information and getting the consensus of a team, I'd personally frame it as "clearly defining the problem". But it might be helpful to have a universally respected team lead or design director who is responsible for directing the process of defining the problem. You need some way to unite the team around a single understanding of a problem. It looks like you're pretty much on this track already.

3) Everyone should take the role of both reviewer and reviewee. There should be a formalized review process and everyone should take turns being on both sides. It's important that everyone on the team understands that reviews are not personal criticism of someone's work but working together to help find the best solution to a problem.

4) Reviewers should learn to deliver feedback in a way that is encouraging and considerate. Be kind. Point out the good, as well as the bad. Ask questions instead of making corrections. Remember to encourage and thank people. One condescending comment in a review can take months to recover from.

5) Reviewees should learn to take feedback as an opportunity to learn, grow, and find better solutions. Feedback should never be taken as personal criticism, even if it was written that way. And reviewees should strive to be open to new ideas and to challenging their own.

I hope those ideas help. Thanks for your comment!

I've heard technical debt (abstractly) as a reason for a lot of these arguments. IE, we can't step back from this argument because the code is important, it will cause all these problems down the road.

But of if course two people disagree on which path is actually correct and which produces more technical debt, what then?