This is essentially the challenge that I've built my career upon solving. I actually prefer to back it up one layer further and suggest focusing on how to get the business and developers to collaborate.

My answer to that question--which I know isn't the original but I think helps solve it--is that bridging the gap is, to a significant degree, the designer's job.

Note that I'm saying this as someone with a dev background but who formally took the UI/UX path, so there's definitely an "if all you have is a hammer" angle here. :)

My view: It is on the designer to have a reasonably strong technical understanding of what the application can and cannot do. IMO, design as a discipline is at least 50% engineering, because how it works under the hood has a dramatic impact on the end user experience.

---

Tips if you're on the design side:

- Ask technical questions, even if you don't really grasp the terminology yet. For example, where is this data coming from? Push the dev team deeper than broad answers ("the data lake"). Is this data cached uniquely for our application? How often? What's the response time? Does it come back in one big query or 15 little ones? Not understanding this results in annoyed devs asking you for loading states you didn't know you needed and will annoy you with a laggy app.

- Ask what libraries and frameworks the dev team is using. Read up on how they work. Walk through demos. If dev wants to purchase XYZ charting library, invest in understanding how it thinks so that you don't design something impossible. Conversely, once you have a good understanding, you're in a much better position to push back when it really matters. By making 90% of the app compatible with the dev team's tooling (which, remember, may have been forced upon them by politics elsewhere), you're buying goodwill for the really important, high-LOE custom bit that really should override dev reticence sometimes.

- For most projects, UI/UX is all about designing systems. The art is in the elegance of the system. The consistency, how it all meshes together, how easy it is to build upon and evolve. Express yourself in the beauty of that first, then add aesthetic exploration on top.

- And I can't emphasize this enough, if you can build your skillset to the point where you can build an average application in a rudimentary sense (i.e. it works, but isn't wired up or scalable), you will open so many doors and understand the dev team so much better.

---

Tips if you're on the dev side:

- Work to view your designer as your advocate and help them want to be it. Your designer should understand the implementation details 90% as well as you do. If they don't, help teach them. Show them how the framework thinks and why you chose it. If both sides come from years of cultural antagonism, this will require a lot of patience from both players.

- Remember that the designer is often reacting to feedback and external pressures just like the dev team is. They're trying to strike a balance between their best judgement (both as an individual and on behalf of users), the dev team's needs, the dreams of the business, and many other stakeholders who may or may not understand the process.

- Understand your designer's background. Even today some digital designers come from traditional design backgrounds and are learning to adapt to flexible viewports, etc. Note also that design tooling, especially in years past, could easily produce designs that exceeded the capabilities of HTML/CSS/et al. at the time (consider Photoshop CS2 vs IE6). It took deep technical knowledge and sometimes reversion of design best practices to reign the tooling in to something that a browser could efficiently support. I say this not to absolve responsibility, but drive empathy. :)

---

Also, shoutout to the answers by thomasqbrady [1] and apricot13 [2], who are capturing the "empathy" message I was trying to go for way better than I did. :)

[1] https://news.ycombinator.com/item?id=32153989
[2] https://news.ycombinator.com/item?id=32151110