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?

  • 5
    Sorry if this puts you off, but I think you got the wrong developers. There are two types of developers: those who care for speed and those who care for quality. Neither is right nor wrong; but UX never fits the first group.
    – kevin
    Commented May 31, 2016 at 15:04
  • 1
    This book has a chapter on how to work with the different roles in a team, I always suggest this book when I hear questions like this! :) undercoverux.com
    – Velkommen
    Commented Jun 1, 2016 at 14:01
  • 1
    What format are your developers given the designs to implement? I take it they are PSD or similar image documents? It can be tedious work to count pixels everywhere, code it up and double check against the design. Annotating the design with all the important dimensions can make this first step much, much easier. Commented Jun 2, 2016 at 11:39
  • 1
    @kevin: that's a misleading oversimplification in more than one way: software isn't just "speed" vs. "quality", and developers don't sqarely fall into one camp or the other, never to be reconciled.
    – peterchen
    Commented Jun 2, 2016 at 15:33
  • 1
    @LcLk: which is why I have recently started using zeplin.io for design hand-off. So I can simply export my styles and assets from Sketch, and save myself and my devs a lot of time and hassle. Commented Jun 2, 2016 at 15:47

8 Answers 8


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.

  • 7
    One of the best answers I've read here on UX.SE.
    – kevin
    Commented Jun 1, 2016 at 8:59
  • 3
    Yes, this really is a great answer, and its usefulness actually goes way beyond this question. Great stuff! Commented Jun 2, 2016 at 10:02
  • 4
    +1 for "Users often won't notice that -- that's the goal".
    – calum_b
    Commented Jun 2, 2016 at 14:44

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.

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.


Ask your developers how they would feel if you went through their code and changed some tabs to spaces (or vice-versa—yes, I have been watching last week's Silicon Valley), or misaligned a few pairs of curly braces.

Neither that nor a few pixels' mis-alignment here or there in the UI has any functional effect, but they both influence the perceived quality in the eyes of their respective end-users.

It's a bit old now, but you might try to find a copy of Designing From Both Sides of the Screen (2001), by Ellen Isaacs and Alan Walendowski—a designer and a developer who, as it happens, are also married.

While the UI design methodologies it talks about won't be new to anyone nowadays, it's written from the perspective of both parties as they collaborate on a (semi-fictional) project. It also talks about the disagreements and misaligned priorities that can arise between designers and developers, and the sorts of things you can do when (as the back cover says) "the ideal design conflicts with other engineering goals".


@David probably has the best answer, so I will only add . . .

The root cause of the problem you are trying to solve could either be:

Lack of strong UI development skills in development (yes this does occur - many developers are not even remotely interested in the UI, but some managers think UI code is just code and developers can write any code).


The relationship you have with development has not matured sufficiently that they trust your judgement (and vice versa).

To fix the first one, development probably need to hire the UI dev expertise they are missing, which is beyond your remit, but would be ideal because things will be much better for you if they have this expertise.

Fixing the relationship to build trust will take time but if development can nominate just one developer to own the UX/UI relationship with you, you can work from there. Education is still a key skill we need to have in our box of tricks so having a single point of contact really helps (verses fighting with the whole dev team) and by working closely with them you can ensure the little things are being dealt with.

There is nothing more disheartening than seeing the execution of your designs not coming up to scratch, and yes the little details do matter (our designs are not suggestions to inspire the developers), after-all the user interface is the only window into your software so quality matters, and design & quality is everyone's responsibility, not just yours.


Whether or not a user notices a detail is distinct from the user being affected by the detail. Amazon increased sales by 1% by reducing page loading time by 100ms. Users likely can't tell the difference between 100ms but they are still affected.

You should regularly run A/B tests to optimize small details in your interface. The developers should know about the results of those A/B tests as they give an accurate picture of the value of the small details.


Yes you are absolutely right. This happens usually that developers think that client just want their project to be completed so no need of pixel level perfection.

But you should stick to this habit and force your team to implement it anyhow, though they feel bad. The reason is if client is not that much educated but if anybody see the website/app they will mark each and everything as we are observing in the case of UX Designing. Initially you have to force them but once they feel something change compare to previous work they will definitely follow pixel to pixel perfection.

I am telling this because I experienced this in my current company. Initially I also get irritated that what is the need of pixel perfection in wireframes too? But then also my senior forced me to make wire-frames pixel perfection. I feel bad now when I see my previous wireframes because my current wireframes shows confidence and expertise of my work. My senior forced developers for 2 years to go with pixel to pixel perfection and now he don't need to tell that !

If any developer argue you that what is the need then just tell him/her that when other people praise your work at that time you feel that it worth to go with perfection. Every time don't consider clients only. If anybody tell your client that your project is too nice,neat and clean, eye catchy then ultimately credit goes to you and in this way chances to get more projects from clients gets high.

I shared my experience,but at last I just want to say again that just change the way to force your developers. Force them to do this with right understanding with some different way.

Refer below link : https://www.thoughtworks.com/insights/blog/ux-designers-why-are-we-wasting-time https://blog.pivotal.io/labs/labs/pixel-perfect-when-designers-develop-and-developers-design

  • I'd have pushed back on the wireframes :) Wireframes are not generally intended to be design specs, and therefore have no need to be pixel-perfect. Making them appear so often leads developers into thinking they are something they are not, in my experience.
    – calum_b
    Commented Jun 2, 2016 at 14:09
  • @scottishwildcat yes but I am trying to explain you that if design or development would be pixel perfect then its effect will be extraordinary. Commented Jun 3, 2016 at 10:45

There is no excuse of not following standards when UX designer asks them to be followed. Let it be pixels, color variation or alignment/ spacing.

UX within an organization requires culture of following. Presence of a UX designer within the team only makes UX guidelines available, but it is responsibility of the developers to follow it and only then your product will end up getting your designed experience.

To make your team follow your guidelines, follow these strategies.

  1. Create set of UX artifacts which are standard. This include
    • style guides
    • typography
    • form elements
    • Interaction rules
    • ux rules
  2. Give your team an opportunity to discuss them with you. If they had a question, objection / suggestion, have it incorporated in your standards. Once standards and guidelines are established, do not tolerate variation to those unless you create those variations.
  3. Design two set of mockups for every screen. One Visual and High Fidelity (if you are making one) and other with Red Lines, Margins and Spacing specified. Some times developer genuinely lack the "designers eye" and cannot judge weather gaps are 10px or 15 pixels. You got to aid them and help them get their job right.
  4. Organize UX sessions within the team from time to time. Everybody has an opinion on UX and they genuinely want to contribute with the knowledge they have. If you find their understanding is based on wrong principles, educate them and bring their understanding on par with yours.
  5. When an un-reasonable variation is made, identify that and correct it giving reference to your standards. Do not tolerate pixel variations or "joyfully coded design".

Hope this helps.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.