It depends a lot of in the skill sets and experience of both people but in most cases the ux designer should be controlling the developer pretty heavily in order to make sure his ideas come through properly.
The UX designer may just need to work on his approach so people don't feel bossed around and more like they are working together.
In an ideal world, there would be a project manager who makes sure everything is communicated well and keeps the dynamic feeling great.
I've provided IA and UX direction for nearly 200 websites over the past 4 years.
The dynamic between a UX and developer depends on both the designer and developer technical skillsets.
This being said, I believe the ideal dynamic between a UX and Developer is to achieve the proposed goal, using the least amount of resources.
Use whatever you have to as a team to get there, so long as you get there.
This is quite simple: Honesty and Openness is the first step to a strong relationship between Designers and Developers.
Designers need to be very open about what they are trying to achieve and why and developers need to listen to that. At the same time Designers need to be very transparent about how they need to do something to get the design working and why that may not work the way the designer has planned it to work - rather than just saying something like 'that won't work' to avoid an argument. Remember rational arguments are a good thing.
And get the developer involved from the start - that's just human nature that you don't want to be left out. The designer should feel like they can ask the developer for advice about the technical implementation - rather than be scared the developer will say no.
The more honesty and openness there is in your work environment the less people are making assumptions about what others think and you will have less friction between resources.
John's right that ultimately there needs to be a Project Manager or someone playing the PM role. Ultimately, there are *always* compromises or at the very least "adjustments" required between what the design team envisions and the engineers implement. Most often, these are compromises to meet business objectives (deadlines and resource constraints) but sometimes, there will be issues around implementation that the design team hadn't considered, depending on the experience and technical understanding of the design team.
I've worked with (and currently work with) brilliant designers and engineers and spend a good portion of my product team managing the tension between the design ideals set forth by the design team and implementation issues raised by the engineering team.
It's almost impossible to expect either camp to effectively reconcile the issues of the other.
Who are you in this dynamic? If you're their leader, then lead. If you need help with that, let me know. Your question suggests you are unsure whether there is an issue at all. If you are genuinely unsure as to whether there is a problem, ask your developer.
A shared attitude between the UX designer and the developer is not only healthy but necessary. Both of them have to focus ultimately on what the users will get, and use. It's not about having the fanciest, most unique and innovative user interface. Nor is it about having the most whiz-bang technology or groundbreaking coding techniques. It's about having a software that will be easy to use, useful, and usable. "Easy to use" because the user interface is intuitive. "Useful" because it does what users need it to do. And "usable" because it works when users need it to work.
The UX designer should be able to explain and illustrate adequately to the developers how the software works, looks, and feels - whether that would entail showing a functional spec, wireframes, or a complete set of mockups would depend on the maturity of the developers, and the ability of the UX designer to explain. But as long as the developers do not fully understand what the product is supposed to be and do, then you will always have problems along the way.
I realized this as a major industry challenge a few years back, as the designer would throw the design that has been completed across the fence and will wait for the engineer to execute it. This would result in either the designer imagining completely pie-in-the-sky scenarios which cannot be engineered within the given timeframe. Or the Engineer building it and the designer later realizing it could've been a much better design. This leads to a lot of back and forth.
For the last 8 years I've actively tried to solve this problem, and have been at the helm of roles which straddle both ends of Experience (Design and Engineering). I am a strong advocate of designers being able to code, and vice versa.
However, this is a very rare hybrid skill-set in the market as of the moment. To counter this, I've worked with teams to have both the designers and developers on the same team, and collaboratively build stuff. The trend that is working very well is reducing time spent on PhotoShop, Omnigraffle and design more so in the eventual medium - which might be the web, for example.
This collaboration helps engineers bring available affordances and interaction possibilities of the medium to the conversation and designers can focus on the larger taskflow solutions and interaction design.
Happy to answer any queries in person, Feel free to reach me.
Developers and designers are both sensitive with feedback, ( guilty as charged) as a UX UI designer i make sure i collaborate through out the project with my developer and team. Goes both ways too. I benefit greatly from developer input and has saved me from making decisions i regret if i had not asked if it could be built. I also agree having a project manager or scrum master in a team is a great idea.
It does depend on the experience levels and responsibilities outlined for each role, but in an ideal collaboration the developer feels like he or she has had input on the designs so that something out of scope or technically impossible is not handed off for development. Likewise, the designer feels as if they continue to have creative oversight and that the UI and UX meet their specifications and that changes are not implemented without first discussing the reasoning and there is agreement on the compromises.