Getting a dev team to understand the importance of small details

If I had to boil down everything I've learned in over 20 years of UI/UX work, it'd pretty much be this.

(I'm copying this over from a Stack Exchange answer I wrote a few years back, basically because I want to be able to link to it as part of my portfolio in a way that will make sense to people who don't live and breathe Stack Exchange. This was written for UX designers; if I were to put together a corresponding essay from the developer's point of view it would... well, it would be the same but different; I may need to think about doing that one of these days....)

Question

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?

Answer

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.