User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
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?
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.
Pick Your Battles
Know The Cost
Usability for the Win
Back Your Request with the Data
Stay Involved
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).
or
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
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.
Hope this helps.
