Q:

Getting a dev team to understand the importance of small details

As we know, in UX design it is important to care about pixel level details in addition to the big picture. Meaning that all UI elements are perfectly aligned, correct colour, etc. 
However, from time to time I get comments like "is this really important, maybe users will not notice this?" from other dev team members. 
What would be the best way to get people understand the importance of pixel precision and small details? Or better yet, is there any good literature about this subject?

A:

I've been on both sides of this one, at different points in my career. Defusing this type of conflict gracefully is extremely important for an organization: once the relationship between dev and design becomes an adversarial one, your product will suck, it's just a matter of time. The "Stand your ground! My way or the highway!" type of response are going to be awfully tempting, especially in the moment, but will be counterproductive in the long run.
There are certainly cases where this is simply the result of laziness or a lack of skill on the part of the developer. We've all seen that happen, 'nuff said.  There are, equally, cases where it's arrogance or a lack of knowledge on the part of the designer -- I've been on the receiving end of layouts for the web that were put together by someone with a good eye but no understanding of how HTML works, which would have been genuinely, and (more importantly) unnecessarily difficult to implement without a bit of adjustment.
But even in the best circumstances, assuming good faith and talent on both sides, this sort of conflict will still arise.  Negotiating this is a long-term process -- below I'm going to be describing the best case scenario to aim for; not all of this will be fully achievable in all organizations or situations, but at least it may give you a sense of what to aim for (or of whether your org is already so dysfunctional as to be beyond salvage...)
Find your allies.  Some developers care more about usability and product appearance than others; some will simply be better at it than others. If your dev team is large enough to have split into front-end and back-end specializations, this sorting-out process will likely already have started for you; otherwise start paying attention to which of the developers seem literally unable to see whether elements are aligned or the wrong color, and (through product management, or individual conversation, or machiavellian intrigue, or whatever works in your organization) try to get the least-interested-in-UI developers assigned to tasks where they can do the least damage.
Get developers involved early in the design process.    The worst case scenario, to be avoided at all costs, is the one where you throw a completed design over the wall to the dev team and move on to your next task, while they're left in isolation to implement it.  The more you can integrate those processes, the better for everyone.
This doesn't mean "ask the developer to do some of the design work" -- but the dev team needs an opportunity to chime in on a design early, to point out aspects of your design that may prove difficult to implement, or even to contribute technical details that could make the user workflow easier. This can also give them time to shape their early development work in ways that will make implementing your final design easier or faster or just plain better.
The social aspects of this are worth mentioning as well:  exposing developers to your design process, rather than just its end results, can give them a better understanding of what goes into the design and why; and conversely it can help the design team to: 
Understand the technical consequences of what you're asking for.  Some design changes are easy. Some would require substantial rewrites of large chunks of code.  It's not always going to be obvious which is which; often it depends on implementation choices that were made years ago.  Maybe the technical consequences of that beautiful design are just too high; maybe there's a different or modified design which would serve the same purpose at a much lower cost.  Part of this is a matter of keeping lines of communication open between the teams, but part of it is the responsibility of the designer to have at least a baseline understanding of how those designs ultimately get built.  The (thankfully increasingly uncommon) photoshop-only designer is simply not qualified to do web design, in my opinion -- they're going to constantly be making design mistakes that they don't even know are mistakes.  This benefits no-one.
Be able to articulate specifically why what you're asking for matters.  I constantly use this as a reality check on my own designs, even when I'm working solo: I find that if I can't describe, in words on paper, why a particular aspect of my design needs to be the way it is, then it probably doesn't.   
It's not enough to say "it looks better this way," you have to be able to explain why it looks better that way.
This is a vitally important career skill. It's crucial for communication with management and with developers, of course.  But it'll also make you a better designer, because it forces you to examine your own work critically, and to understand in a rigorous, methodical way, which aspects of your design actually work well and which ones are just pretty.  Pretty is important, but it's not sufficient.  
(The "users won't notice that" thing, incidentally, is a red herring.  Users often won't notice that -- that's the goal; if they're noticing something, it probably means they're noticing a problem.  Users also don't notice whether the dev team has normalized the database properly, or whether they picked framework X over framework Y, but that doesn't mean those choices are unimportant. Similarly, most users may not consciously be aware that an element is off alignment or a slightly wrong shade of blue, but enough of those will contribute to an overall impression of sloppiness or lack of polish.)
Prefer style guides over mockups.  A mockup, by definition, only covers a single program state; it's not possible to build mockups for every possible situation, so at some point or another the developer is going to be left to come up with a way to cover some case you didn't think of.  If there's a solid, comprehensive style guide in place for the project, they're much more likely to come up with something that works.  If there isn't, they'll either have to come back to the design team to ask for more mockups, or they'll just wodge something together the best they can.  You know how well that usually works out.
Another advantage to style guides over mockups is that it makes the developer more involved in thinking about the design as a design.  Few people enjoy just doing the grunt work of fulfilling someone else's plan to the letter -- it's much more engaging and motivating to be empowered to contribute to that plan, if only in small ways.  Given a good set of ground rules, most (admittedly not all) developers will be more than capable of doing so.
And a third advantage: it keeps you honest as a designer.  It's easy to inadvertently gloss over the hard parts of a design when building a mockup: your lorem ipsum fits tidily in the space available, the amount of content is always just right, that messy edge case dialog box isn't necessary, etc. Designing rulesets and guidelines, rather than individual screens, forces you to think about the product as a system rather than as a collection of pretty pictures, which always benefits the end result. 
Choose your battles.  "Pixel perfect design" is not actually the goal, and it's very important not to slip into that mode of thinking.  A completed, usable, attractive product is the goal.  This, as with all other aspects of design, is a matter of acceptable compromise between competing interests; this necessarily includes the developers' interests.  
The fact is, some pixels are more important than others.  Before wading into a fight on any particular issue, make sure it's going to be one for which the payoff is worth the battle.    Be prepared to accept pushback and critique from the developers just as you would from management, sales, and end users, and do your best to work with them rather than against them.

A:

When you get reactions such as this from your dev team, then you could try asking them from what point onwards they think users might actually start to notice details. It might give you an insight on how they perceive UI and UX, and give you another way of discussing this together.
There's also a difference between consciously or unconsciously noticing UI. For example, some users might not be able to see the difference between two texts with a slightly different letter spacing, but they will probably find one or the other easier to read.
My solution to this problem is basically recognizing my dev teams' level of expertise, which I do everytime I can. I truly admire developers, and as far as I'm concerned, they are truly wizards within their field. But I don't have an opinion on how they should build their queries or which CSS preprocessor they should use (because, well, users probably won't notice).
The basis for a healthy relationship with your dev team is respect and recognition. If you can give them that, then you're entitled to receive the same.
And my solution for ensuring the design is pixel perfect, is to have dev reserve some time towards the end of the project for me to go through every detail that needs fixing together with a developer. So, basically, sitting next to them, and tackling every issue together with them (make sure to bring snacks. developers love snacks).
This definitely works for me. Perhaps this might work for you too.

A:

Pick Your Battles

Not every pixel is worth the effort. If the corners are squared off in IE8 but rounded in all the other browsers, how much dev time is worth investing to bring IE8 up to snuff?

Know The Cost

Some changes - like matching a color - are almost always quick to implement. Others can be deceptively difficult, like "align the baselines of these two disparate yet responsive elements." Anything's possible, it's just a question of whether your budget has enough time and money to devote to it.

Usability for the Win

Do your requests have a usability component? Refactoring code that your dev team has already signed off on seems more noble if there's a mission like making sure your site remains accessible to all (and your company avoids litigation).  

Back Your Request with the Data

Going back to a developer with usability testing data depersonalizes your request. It's not just that you're being picky, user testing heat maps show that there's trouble finding the call to action to complete their user journey.

Stay Involved

Building in clear design and accessibility is easier and more effective when you start from the foundation. Let your developers know the design assumptions and accessibility parameters from the outset. If you're all pulling toward the same goal, there will be less refactoring and less friction between design and development.

