I will start off by saying that I know the best way to defend design decisions is not to. That's what data (quantitative and qualitative) is for.

But the product I'm working on doesn't have that. What it does have is a development team who's jaded after four different product teams have churned through in the four years the product has existed, and who have been outspoken from the start that they're not inclined to implement anything we ask them to unless we can prove to them why it should be done.

The "why" answer is that the product doesn't meet the need it was designed for. Its grand total of zero users is a reflection of that. We've conducted user and industry research supporting the direction we're taking the product in and what we'd like to accomplish, but we don't have the resources (specifically access to a large enough sampling of the target users, who are in a specialized industry, or the money to incentivize them to participate in research) to conduct user testing or an additional round of research for every change.

And they want it for every change. Even something as small as adjusting button placement (to create consistency across the entire product) was met with pushback. "Why do we need to do this? Did users ask for this? I don't think this is a good use of our time." I'm not exaggerating when I say that one of the devs will go so far as to swear at us (the product team) when sharing their opinion on what we're asking the team to do.

We don't leave dev in the dark about what's coming up. I, as the UX/UI person, touch base with them regularly to get their input on my proposed solutions and work with them to make adjustments based on our architecture or resource limitations. We'll all come to an agreement, then we'll get into the meeting where we introduce the new feature and they'll still tear into it.

My team is exhausted. After two years of working with the developers I feel like I've done everything I can think of within our current limitations to make dev feel informed and included in the process of developing new features, but at this point it feels like what they actually want is to spend their time shuffling deck chairs on the Hindenburg (or as they like to call it, refactoring) rather helping us do the work needed to make this a viable product and, by extension, help us all keep our jobs.

Has anyone else run into a situation like this? In the absence of qualitative/quantitative data, what can I do to get Dev to stop throwing a wall up against every UX and product decision?

Edit: And regarding my relationship with the developers as individuals, if you'd asked me a year ago I would've said it was good, but as our changes to the product have grown more ambitious (in keeping with what we discovered with the research we were able to do when our team came on board), the dev team as grown more distant and hostile. I do know at least one of the devs--the one who swears at us in meetings--has no desire to change anything he's worked on and will fight us to the death if we ask him to.

1 Answer 1


Firstly, this sounds like more of a breakdown in your organizations decision making process, as opposed to the UX/Dev relationship themselves.

Do you have any formalized method for how various tickets/initiatives get reviewed and decided on? WSJF? Backlog grooming? Sprint planning and retros?

Where is the business voice in these decisions? There are likely many situations where refactoring is more valuable than adjusting button placement for consistency, and vice-versa. But how is that value being evaluated and decided upon.

This is a great article for feature prioritization and balancing high value decision making between dev, ux and business: https://medium.com/design-bridges/feature-prioritization-a089fd0af08 I'm currently pushing such formalized decision making at my organization. We're currently rebuilding our entire system of applications, as well as I'm handling smaller improvements and updates. So I get lots of situations where my official UX Recommendations are the correct recommendations, I'm pushing them forward expecting a compromise because I know the proper solution is coming.

Secondly, you have some options for UX methods to defend small changes. For all my smaller support tickets I'll learn heavily on Usability Heuristics evaluations. I'll outline all the current violations and connect all my recommendations back to the heuristics. https://www.nngroup.com/articles/ten-usability-heuristics/ Currently I'm working with a very kludged together UI. We are building a Design System for our re-imagined initiative, but everything in field is very inconsistent. So with my small tickets efforts and large revamp efforts I am always writing down rules and guidelines. No, they don't all get implemented right away, but if rules aren't documented and easily accessible dev won't have the autonomy to make some decisions inline with your expectations.

Thirdly, it definitely sounds like your past the point where more formalized decision making, and quick evaluation point on small changes will be enough to bridge this relationship. I spent years at an ad agency bringing the UX maturity up from non-existent to stage 3, pushing on stage 4. It was the creative team that was my biggest challenge there. They wanted to do whatever they thought was cool, and amazing regardless of the massive dev efforts required, or that it would slows down all the users who actually have tasks and objectives to complete.

I did A LOT of UX theatre, just conducting UXR activities internally with dev, creative, and stakeholders as my participants. My goals here was purely evangelizing, building excitement, and demonstrating value of the UX process. This was mostly handled through User Flow reviews, Usability Heuristic evaluations, 5 second test and 1-click tests. All limited value in terms of actual user insight but highly valuable in building trust and excitement for UX.

Maybe sometimes adjusting a button placement for consistency is the wrong choice. Obviously those changes should be made and a consistent interface is a worthy goal. Don't die on those hills, document your recommendations, keep all your rational accessible for the long-term.

  • I can't stop thinking about this. It's such a hard place that you're in. Reach out anytime if you want more ideas and suggestions. I've faced way more disputes and experimented with way more solutions or resolutions in the UX space, than I could possibly post in one answer. I'm also trained in some conflict resolution and de-escalation. I don't use these in the workplace, it's all related to working safety and security at some multi-day, high substance music festivals. Lots of tips and trick that can help turn a competitive/combative workplace relationship into a more collaborative one.
    – It's Dylan
    Jan 23 at 20:55
  • 1
    Thank you for such a through response! When our product manager (my boss) came on board, he worked with the dev manager at the time to implement the backlog and story rituals you mentioned because he realized that the team was not set up for success with their current structure. That was about a year ago; I'd say from a purely "Getting things done" perspective the process is working--it's getting to the "Getting things done" part that's the challenge. We have weekly meetings to review and prioritize stories, and that's the time the dev team uses to push back. Safety in numbers I guess? Jan 24 at 2:00
  • 1
    It's funny you mention building out the design system documentation--that's something I've been doing in Figma both for personal sanity and for front end dev reference, but I was just thinking I should present that information in a way that helps dev and any new designers who join the team feel confident about what to use and when. A usage guide to the system outside of Figma would be good for that. Jan 24 at 2:03

Not the answer you're looking for? Browse other questions tagged or ask your own question.