More on my previous post about Redlines.
The problem is that if you are not experiencing the exact problem as everyone else on your team, you will inevitably build build a different product. This is outsourcing. Outsourcing doesn't work unless the terms can be easily and explicitly stated. And, don't just think this is about shipping over continent boundaries. If the work is outside the same office, then you're going to have problems.
At its heart, the problems lies in the fact that the developer isn't sitting right next to the designer. In which case, the developer is building a different solution than the designer is designing. It's gets worse because companies break the two disciplines into completely separate teams. We have a technical team and a design team--which doesn't work. The company was based on building products, yet they destroyed that end in favor of the means--it's easier to manage 2 teams, in which the management is geared at the exact discipline.
My colleague is working on an article along the lines that the design is simple, the implementation is the hard part. So, it's all about execution. Who can execute on the vision? Who can break the outsourcing (from one desk to another down the hall)?
It gets worse. Not only does the designer have to sit next to the developer, they have to be on the same page. They have to understand the process. They have to work as one and deliver on the same vision. Although, this doesn't mean that the developer should constrain the designer with technical hurdles. Under no circumstance should a designer understand the technical implications. Just build a great vision and do what you can. Then, at last sight, you figure out what can't work and ask for more iterations on that feature, hopefully trying to ferret out a better idea, that can also work tecnhically. Iterate, iterate, iterate...
As a developer, you must understand design. In most cases the developer is the primary guage for interaction design, because in building and testing a feature, they get the first glimpse into its usability. Therefore, they should understand how to run with ideas on bad interaction design and change the feature. Then, they can show the designer, and a democratic decision can be made (it's hard for a visual designer to understand the implications of interaction from photoshop--they need something to play with).
So, remember, although the developer is the ultimate gate keeper for a product, they are also expected to understand design. The disconnect between the two disciplines must be dissolved immediately. It's not about the code, it's about the product, the experience, and the emotion.