Whether intentional or not, this is how lots of companies decide to structure their staff.
Techies over here, non-techies over there. You guys just toss stuff back and forth over this fence and we'll pretend that everything will just come together magically!
This, of course, simply doesn't work. The non-techies aren't treating you badly per se. They're just treating you the same way you are treating them. Both parties likely don't even realize it.
The issue isn't disrespect between groups--the issue is an incredibly poor org structure and work process.
What has happened in your specific case is something I've seen happen in many orgs I've worked at. Have someone 'design' the solution, then have technology 'build' the solution.
This stems from the concept that producing software is somehow related to the factory floor process.
Team 'a' designs the solution, team 'b' works on the factory floor to make it.
What many organizations fail to understand is that software takes place entirely in the design phase. The end product is the design. So there can't be a team 'a' and a team 'b' that work independently and sequentially.
There has to be a single team that has you techies as part of the design process and working in parallel.
How to fix that? You probably can't. Agile development and Minimum Viable Product and other processes are designed to help with this, but I haven't seen many companies that didn't embrace those from the start ever really transition fully to them. They drag a lot of baggage along with them.
Finally, to answer the very specific scenario you describe, the frustration is often because the UX/UI/Design/Art team are tasked with creating a solution. However:
- they may not have technical skills or allowed to deal with implementation
- often have to deal with appeasing management who may or may not have ideas that make sense in terms of viability and often care even less about the pragmatic issues of implementation.
- are often responsible for the design being finalized before a line of code is written.
- are often not in communication with the implementation team from the start (usually due to the aforementioned org structure and processes)
This, of course, confuses the implementation team when they first see the solution. Inevitably there's a lot of issues that likely need to be resolved and since they weren't part of the process at the beginning, these all seem like brand new issues. This frustrates the team that handed the project off to you because the solution has already been approved. It's not your fault, of course, but you'll likely be the one to get yelled at (as they can't easily go back and yell at management).
I've seen this happen in many companies and have been on both sides of that fence before. And that's probably the best way to eventually fix situations like this. Get some cross-trained generalists hired on both teams. This can really help bridge the communication and process gaps.