
Why you should move that button 3px to the left - axelbouaziz
http://www.gv.com/lib/design-details
======
sxp
So why should you move that button? The article doesn't actually answer the
question. If a UX designer just says "move the button by 3px because it looks
nicer", then there is a good chance that someone higher up the hierarchy will
say move the button by 4px because that looks better. And since neither of
them are able to actually justify their reasons beyond some vapid and
subjective claim of making the product "more delightful", the person with more
seniority wins.

Contrast this with the engineering version of this debate where the decision
between using foosort and barsort can be decided based on which one results in
lower CPU usage. Or a UI element is moved 3px because it allows reducing the
depth of the UI widget tree which improves the FPS by X during complex
animations. Or that a button's bg shouldn't be #282828 because of the problems
with 16-bit color.

The other big problem with quibbling over 3px in Photoshop mocks is that the
mocks tend to be designed on high dpi displays using Photoshop or Illustrator
which do not need to handle realtime rendering so they use high quality
antialiasing and scaling. When the mocks are implemented, the final product is
viewed on a multitude of devices with different rendering characteristics. So
the 3px change might result in a blurry line because the widget no longer
snaps to the pixel grid of the lower resolution device after the system scales
the image to handle resolution independence.

So if a designer asks for a 3px change without justification, then the
engineer should push back until a good reason is given. There are objective
aspects to UI and subjective aspects. Discussing the former is straightforward
and the decisions are relatively easy to make. But discussing the latter
quickly degenerates into bikeshedding.

~~~
Chris_Newton
_And since neither of them are able to actually justify their reasons beyond
some vapid and subjective claim of making the product "more delightful"_

Do you appreciate the irony that you just wrote a whole post about making
decisions objectively, in which you have essentially dismissed designers as
ignorants who just make arbitrary decisions according to their personal
whimsy, based on a series of unsubstantiated claims, out-of-date stereotypes,
and straw man arguments that any half-decent designer could have corrected for
you in moments?

Why would you think a designer would have no justification for a change beyond
“it looks nice”? What would you assume designers don’t understand issues like
pixel alignment or designing for multiple devices? Why would you think
designers would be raising these issues based on Photoshop mock-ups?

Do you understand that there is actual research underpinning a lot of design
theory, demonstrating both how humans respond to different design choices and
the fact that those choices can directly and sometimes dramatically affect
metrics you care about like conversion and retention rates?

 _So if a designer asks for a 3px change without justification, then the
engineer should push back until a good reason is given._

I wonder how you’d feel if you as a developer were told that every line of
code you wanted to change — even those with obvious bugs — could not be
touched unless you had previously demonstrated why you expect a measurable
benefit to the satisfaction of the business development staff, and that your
commit access was going to be revoked and every change would have to be made
by bizdev after someone who didn’t know anything about programming decided
whether it was justified.

~~~
sxp
_Why would you think a designer would have no justification for a change
beyond “it looks nice”? What would you assume designers don’t understand
issues like pixel alignment or designing for multiple devices? Why would you
think designers would be raising these issues based on Photoshop mock-ups?_

Experience. I've had arbitrary requests made based on Photoshop mocks. I've
pushed back against them after showing that the proposed design looks blurry
on devices with a low dpi. Or showing that the UI breaks down in edges cases
where the text field contains more text than what is shown in the mocks which
results in unwanted wrapping. These are issues that can only be understood by
someone who knows the implementation details and constraints of the underlying
OS that does the final work of rendering the UI rather than relying on the
constraints of Photoshop.

 _Do you understand that there is actual research underpinning a lot of design
theory, demonstrating both how humans respond to different design choices and
the fact that those choices can directly and sometimes dramatically affect
metrics you care about like conversion and retention rates?_

Yes. And good UX designers know this research which is why they can quickly
justify their choices.

~~~
Chris_Newton
It sounds like your real problem has nothing to do with a “design version” or
an “engineering version” of anything. You’ve just worked with some people who
were in a design role but didn’t know how to do it. That’s unfortunate, but I
don’t think it invalidates the original premise of the article that paying
attention to seemingly minor design details matters more than a lot of non-
designers tend to acknowledge.

~~~
jessedhillon
I have yet to see a proposed application design or cosmetic change whose
justification does not ultimately rely on "this guy's taste is better than
that guy's" \-- yes designers do sometimes bring out some justifications which
are expressed with objective sensibilities but to me they always seem to be
rationalizations, in the same way that evolutionary psych seems to be. That
is, first see a behavior or a look that seems appealing, then figure out which
design principles are making it seem better. I think the best designers temper
their taste and predilections with judicious application of statistical
methods such as split-testing.

I don't find anything objectionable about this, as long as the designer
_actually owns_ the design and has the fortitude and clout within the
organization to defend their changes. Design seems to me an art in many
respects, so some decisions will come down to a matter of taste in the end.
Like any successful artist, the designer then will need the persistence to
defend their vision against the meddling of bike-shedders.

I also think @sxp's characterization of the objectivity of engineering
decisions leaves too much out. Engineering debates rarely come down to
foosort() v. barsort(), where one obviously performs better. More often, they
come down to questions like "should we be passing this argument first or
last?", "what should these methods be named?", "can this code be extracted
into its own module?" \-- in other words, how to design the code.

~~~
nikatwork
You're not working with properly trained designers then. Layouts have certain
empirical properties which can be judged objectively:

    
    
      * Conforms to a grid
      * Internally consistent padding and margins
      * Information sized and arranged hierarchically according to importance
      * Proportions conform to the rule of thirds or golden ratio
      * Internally consistent UX patterns 
        (eg cancel buttons might be always red, confirm buttons might be always green)
      * Text column widths are not too wide
      * Color choice is harmonious (conforms to color wheel rules)
    

These are the main ones but there are many others. Unfortunately, these kind
of classic design principles don't seem to be taught very often these days,
instead design courses focus on the mechanics ie how to use Photoshop.

~~~
hueving
Is there strong scientific evidence that when one of these is slightly
violated, it will negatively impact the user?

~~~
Chris_Newton
The short answer is no, slight violations of these ideas don’t tend to cause
the sky to fall. Indeed, the list of examples given by nikatwork was
unfortunate, because some of them are well established with a decent evidence
base, but a few are basically just nonsense that has unfortunately somehow
become dogma.

For example, a few studies have been performed under controlled conditions to
try to determine how typographic details like line length affect measurable
performance levels such as reading speed and retention. There are many rules
of thumb floating around — “2.5 alphabets”, “8–10 words”, and the like — and
it actually does turn out that most of them are reasonable. It also turns out
to be unwise to consider line length in isolation, that a wider range of
lengths can be used before serious degradation is widely observed than some of
the old folklore would suggest, and that having lines too short can also cause
serious degradation in reading performance, among other interesting results.

Another good example is the consistency of user interface elements. Numerous
usability tests, from formal studies to simple A/B tests on web sites, support
the theory that violating a user’s expectations tends to have negative
effects, sometimes severe ones. Of course you always have to be careful not to
assume too much about what your users’ expectations might be, but things like
using green for cancel and red for confirm almost invariably exhibit poor
performance with audiences who are used to the opposite convention.

On the other hand, if someone tells you the Golden Ratio is important for
keeping some sort of page area proportionate, it’s a good bet that this person
should be hunted down and locked away by the maths police. Using precise
ratios really does matter in some contexts: if you look at the ratio between
the width and height of a piece of A4 paper, it is aiming for exactly √2,
which is why two A4 sheets fit neatly into one A3 sheet and so on up and down
the scale. However, someone who is advocating use of the Golden Ratio for
width/height proportions usually just likes the look of dimensions that are
proportioned roughly 5:3, and probably has no hard data to support choosing
that over 3:2, 16:9, 1:1, or any other ratio that fits with the rest of the
design.

Likewise, if someone advocates picking a colour scheme based on where certain
hues fall on a wheel, consider that hue represents only one dimension. The
most common colour models for human vision use three, and in practice if you
fix the others (typically saturation and lightness) and just choose evenly
spaced and/or opposing hues around a colour wheel, the results are rarely
good. That means much repeated ideas like choosing analogous or complementary
colours are, at best, only part of the story. If you’re using a typical colour
wheel for computer graphics that has red, green and blue at 120 degree
separations and then cyan, magenta and yellow on the 60s, those ideas are even
less helpful, because it turns out that by the time the human eye has detected
the light and the human brain has interpreted the resulting signals, those
colours aren’t really uniformly spaced around the wheel anyway; see the
trichromatic vision and opponent process theories, or the early experimental
work of Munsell.

In short, there really is robust evidence that some established design
principles are worth following, though rarely do minor variations in design
cause major variations in performance. However, there are also some dogmatic
assumptions in the design world that get passed on as if they are inalienable
truths but in reality have little evidence to support them.

~~~
nikatwork
We're talking at cross-purposes here. My point is that if someone hands me a
layout with wildly inconsistent internal margins, no call to action and a text
column that is a full screen width wide, I can objectively say those elements
are wrong and need to be fixed.

Of course, the other side to design is "style", which cannot really be
quantified, merely subjectively judged against current trends, the target
audience and "taste".

~~~
Chris_Newton
Apologies if I misunderstood your previous post. From your final paragraph
before, I thought you were arguing that the properties you listed were not
only things that could be judged objectively but also desirable principles
that should be taught as part of design courses. I was countering that this
would have been OK for some of the items but dubious for a few others, because
while they are widely held and promoted beliefs in some quarters, they are
also examples of things many designers say that _aren’t_ backed up by rational
arguments or empirical data.

------
crazygringo
This is a fantastic article.

To people below who say the designer should make the change him or helself --
as a front-end developer, I say a million times, NO NO NO. Does the designer
know how to use git and commit properly? Do they know on what branch?
Understand the deployment schedule? Perform browser testing? Are they part of
code reviews? Do they understand whether that rule is used by just that
component, or just that page, or if it will affect code elsewhere?

I think it's _great_ when designers know enough to code the CSS of their own
portfolio or blog, and can converse fluently about the concepts. But unless
they're true hybrid designer-coders who are participating fully in dev
meetings, please DO NOT touch the code. I've seen sites break too many times
before, because a designer changed something they didn't understand, and which
there was no reason for them to understand anyways. (And to anybody who would
say a designer should understand their tools, well it's not like most print
designers can operate a printing press either. Design professionals design,
and generally other professionals actually implement those designs.)

And to anyone who replies "design has caused real harm to the WWW", sorry
buddy, that boat has sailed, and makes as much sense as saying we should
expect Rolling Stone magazine to come in a dot-matrix text printout instead of
a glossy, attractive magazine. Design is important, period.

~~~
Pxtl
> Does the designer know how to use git and commit properly? Do they know on
> what branch? Understand the deployment schedule? Perform browser testing?
> Are they part of code reviews? Do they understand whether that rule is used
> by just that component, or just that page, or if it will affect code
> elsewhere?

If he doesn't, find one who does. A web-designer who doesn't understand code
is like a fashion designer who can't sew.

~~~
colmvp
> A web-designer who doesn't understand code is like a fashion designer who
> can't sew.

Except there are successful fashion designers who rarely if at all sew, just
like there are successful interactive designers who rarely if at all code.

Do I think knowing how to code typically makes a designer a better designer
than others? Yes. Do I think it's always that way? Hell no.

------
underwater
Engineers don't look at a finished product and see something that's a few
pixels away from perfection. They know all the kludges and hacks that are
hiding behind the scenes. As a designer it's your job to help them get past
that.

Being able to communicate is one of the most important skills a designer can
have. If engineers don't understand the importance of good design that is your
failing, not theirs. Talking about delight and pixel-perfection to the wrong
audience just makes you sound like a Jony Ives wanna-be.

Merely asking everyone stops to sprint towards a perfect design shows a lack
of empathy towards your team mates. At launch time everyone has features they
needed to cut or temporary hacks they never got to fix. Telling team mates the
most important thing is to "perfect" a vision they haven't bought in to is not
a convincing argument. And viewing their hard work as a "sloppy version of my
design" is not likely to win favors either.

The most effective designers I've worked with have been able to create and
also sell their design. They can express both the motivation behind their
design as well as the importance of implementing it well. They haven't just
dictated design from up on high.

~~~
ssully
That first sentence got a bigger response from me then I was expecting. I
can't even tell you how many times I've been told a project I worked on looked
great, but I struggle to believe the person because of the numerous
improvements I know can be made.

------
valtron
When I used to work with my designer friend, he would tell me to do things
like that: increase this padding by 5px, lighten the color by a little,
slightly decrease the border-radius, etc. One by one like that, I find it hard
to follow and it doesn't feel like anything really looks different -- until I
compare the finished product with what I originally made by myself.

Anyway, slightly OT: the screenshot looks like a Google page. Does anyone know
which one? I really want to know what difference the 3px makes!

~~~
DanBC
Did you show your designer friend what happened when someone presses ctrl +?
Or uses a different browser or loads their own fonts or etc etc etc?

Designers have caused real harm to the WWW. They're clearly not the worst
thing about WWW but they're pretty bad.

~~~
valtron
No, but I just checked a few of the sites we made and none break from ctrl+
(regarding this: I've never seen a non-tech person, i.e. 99% of traffic for
the sites, use shortcuts in the first place); they also look consistent
between _modern_ browsers; and how often do people load their own fonts? Is
the designer responsible that a site becomes unusable under Wingdings? (Sorry
for the strawman.)

That being said, when a designer says things like "move this button 3px to the
left" they usually mean things like "move this button so its right edge aligns
with the right edge of the content below, which got shifted because we added
padding-right." So the original request gets implemented as what he _wants_
rather than what he asked for.

~~~
chimeracoder
> Is the designer responsible that a site becomes unusable under Wingdings?
> (Sorry for the strawman.)

Rather than apologize for making a strawman, how about we not make one in the
first place? Nobody's talking about dingbat fonts from the 90s - GP is talking
about usability _today_.

> No, but I just checked a few of the sites we made and none break from ctrl+

I'm glad your team has thought ahead, but I can assure you that many have not.

I can't count the number of sites that I've seen that would be completely
unusable for people reliant solely on mobile devices (used as primary
computing devices in the developing world), for people who rely on screen
readers (blind and otherwise disabled people exist too!) - I could go on and
on.

The common rebuttal I hear to this is that "the average user doesn't care
about this", and the website isn't designed for "edge cases", which always
makes me cringe. The wheelchair ramp at your storefront may not be used by
your "average" customer, but that doesn't mean you shouldn't have one, even if
the law didn't require you to[0].

Amusingly, in many cases, the sites that are the best-suited for a range of
devices (desktops, tablets, phones) _and_ clients[1] are the ones that look
like they stepped out of the late 1990s.

[0]
[http://www.adawheelchairramps.com/modular_ramps/ada_modular_...](http://www.adawheelchairramps.com/modular_ramps/ada_modular_ramp_specs.aspx)

[1] Take a minute and check if your site works in Lynx. If not, there's a very
good chance your site is inaccessible to visually impaired people (yes, Lynx
and similar browsers _are_ still used by people with disabilities today!).

------
nahname
>As designers, we are held responsible for the overall quality of the
experience. Yet we’re at the mercy of our teams

Part of me empathizes and sees the similarity. Another part of me wants to
point out that there is nothing stopping the designer from fixing this
themselves. Learn your medium.

~~~
chc
Some companies have rules that actually do prevent people from just diving on
and doing whatever they want with the code.

~~~
dredmorbius
Demonstrating a change in a local repo, or even with a local CSS stylesheet,
isn't "doing whatever you want", it's a prrof of concept.

There ate plenty of broken corporate cultures out there.

~~~
dredmorbius
s/ate/are/ damn you mobile

------
ryandrake
Prove it. Measure it.

Demonstrate with data that moving that button 3px to the left will increase
sales by X% or customer retention by Y% or whatever our business metrics are.

There's a difference between "obsessing over the details" and "tweaking for
tweaking's sake". Make sure you're really doing the former and that the
particular details you're obsessing over matter measurably.

~~~
arrrg
Yeah. And then you find out exactly why social sciences are progressing so
slowly and have such a tough time of getting definite results.

I envy everyone working in natural sciences. Their jobs are immensely
challenging, no doubt, but at least they have a clear path forward, more or
less. But they are making impressive progress all the time.

Looking at human behaviour is much more challenging (so challenging that
hardly anyone has an idea how to do it and most stick with boring unreliable
ways that have somewhat kind of worked in the past), fraught with ethical
issues, and so on.

Measuring everything is not a realistic goal. Measuring should be done
whenever possible and is an awesome tool every designer should be using but it
is impossible to employ it for every little change. And it has so far not been
possible to develop a general theory of design that would help you decide
small things without testing that specific instance of the design.

------
d0m
It's also that for a designer that 3px is HUGE.

It's like if you see this in your code:

    
    
      print 1
      print 2
      print 3
      print 4
      print 5
      print 6
      print 7
    

Any programmer would refactor that in a heartbeat without thinking too much
about the impact or if it really matters.. it's just a plain bad smelly code.

For a designer, unaligned things is just as annoying. It's not that much about
if other people can see it. Some will "feel" it, some will clearly see it,
some won't see it. But it's just smelly wrong.

Yes you could make a point of not tweaking it, but it's faster anyway to fix
it rather than discuss it.

------
aresant
"How do we convince our engineering and product counterparts to care about
design fit and finish?"

I expected the first answer - especially from Google ventures - to be "show
them through data / testing the power of getting the details right".

Marissa Meyer's infamous "we once tested 41 shades of blue"(1) was the nexus
of Google's design culture in the 2000's, has this changed?

(1)
[http://www.nytimes.com/2009/03/01/business/01marissa.html?_r...](http://www.nytimes.com/2009/03/01/business/01marissa.html?_r=0)

------
gruseom
Wow, this is a superb article that resonates with me as much as anything I've
ever read on the subject. It practices what it preaches, too. Reading it made
me feel the very things it's talking about.

I sense, though, that the author's tactics for working with teams that don't
share his values are half-measures. It reminds me of the large and sad
literature on "organizational change" in software development, wherein people
trade stories about how to cajole managers into letting them do fragments of
good engineering. None of that works very well. The satisfying solution is to
be part of an organization that values good engineering in the first place.

Similarly, a designer like the author would be better served by working
with–I'm tempted to say _better_ engineers, but that's my bias–engineers who
feel the same way that he does about product. These exist; I'd consider myself
blessed to collaborate like that.

~~~
Chris_Newton
_...engineers who feel the same way that he does about product. These
exist..._

Unless my personal experience has been wildly unrepresentative, software
developers tend as a group to be almost obsessive about getting fine details
right. We’re the guys who worry about whether our design will be as easy as
possible to maintain in the face of arbitrary future requirements or whether
using some clever data structure would have given 0.07% better performance. We
know, rationally, that sometimes our work is good enough and that we need to
move on to other useful things, yet still there is a little voice in the back
of our heads telling us we should have done better.

If I were to pick one other group who tend to exhibit the same trait, it would
be designers. There ought to be a natural camaraderie here that makes it easy
for little details to get done right. If that’s not the default outcome, and
probably something that people in management and sales regularly have to
balance with pressure to ship, the first question should be why.

~~~
kybernetikos
To the developer, every decision is a trade off, a tension between the demands
of the now (features and time) and the demands of the future (elegance,
maintainability).

Designers are not in a good position to appreciate the trade offs. It's very
easy for a designer to think 'this infelicity decreases delight, and fixing it
involves _just_ moving this thing to there'. This is probably an excellent
spot of a real design issue, but that isn't the only thing that determines
whether the work should get done or not.

I have no solutions, but problems like this are generally because of an
insufficient appreciation of the other professions challenges, and if you're
working in an environment with skilled practitioners of both disciplines, more
communication is likely to fix it.

Here are some suggestions that might help designers talk to developers: Never
use the word 'just' when talking to developers, frequently apparently simple
things have huge ramifications and just as a designers specialty is
understanding how the little things create a full experience, a developers
specialty is understanding how little changes affect other things in the full
system. Talk to them about the effect you're aiming for, rather than just the
change itself - if the change is trivial, the worry is that you're not
respecting their time, but if you convey that the trivial change will have a
large specific effect then they will understand and may be able to do other
things proactively to help you achieve your effect. Show that you care about
more abstract values such as 'maintainability'; the ability to add features
quickly in the future and having a low bug count are both massively beneficial
to the user experience. Where you can, show that your fixes are not merely
matters of opinion but are based on empirical evidence, good developers
respect evidence. Get involved early in the process and talk regularly to the
people implementing the design - show that you care about their opinion, but
educate them in seeing things from another viewpoint too.

As a developer, you are probably used to having a discussion with the person
who reported a bug for technical issues. Do the same for design issues - even
if it's just 'move this button three pixels', talk to them about it, find out
why it's important, find out if they really mean that it needs to align with
some other element. If you have a legitimate reason to not want to do it,
explain the problem - you might be able to work out a better solution
together.

~~~
Chris_Newton
_Never use the word 'just' when talking to developers, frequently apparently
simple things have huge ramifications_

Sometimes that is true, and that is so whether you’re talking about changing a
design or changing the underlying implementation, and whether you are talking
about web design/development or software development more generally.

Having said that, if a designer can’t request and a developer can’t implement
trivial changes that really are as simple as shifting something by 3px, most
of the times that means at least one of the following is true:

1\. The person who implemented the previous version wasn’t very good.

2\. The person who implemented the previous version was pressured to take
short cuts in order to hit time/money targets and produced work that wasn’t
very good.

3\. There is some more general problem with the development process that means
a designer requesting a trivial change and a developer then making it are
expensive when they shouldn’t be.

Obviously there could be exceptions where that 3px change has much wider
implications for the overall layout, but I don’t think those cases are really
what any of us are talking about here.

~~~
kybernetikos
The point is that if you use the word 'just' you're saying that you already
know that the change is trivial. Perhaps it is, perhaps it isn't. Show respect
to the person who will implement it by letting them say whether its trivial or
not.

It's absolutely true that moving a button 3px should be trivial, but it's also
true that things are often not as they should be.

~~~
Chris_Newton
I agree with your fundamental point that making the assumptions about what
colleagues will have to do can be dangerous, though I would still challenge
your earlier suggestion that apparently simple things “frequently” have huge
ramifications. It’s sensible and polite to acknowledge the possibility, but if
trivial-seeming changes are getting push back more than occasionally, IME that
probably indicates a more serious underlying problem with how the project is
being built.

------
rmetzler
Maybe designers should learn a little bit of CSS and git and just fix the
pixels.

~~~
lincolnq
This article makes a strong case for that.

Things like "grab me before you check this in" and "we need a design fix-it
day" are indicators that this problem has a high communications cost between
the designers and engineers who have to implement those designs. Companies who
observe symptoms like this should consider hiring a designer/engineer instead
of having those two separate people. Yes, the combined person will be more
expensive but they will just do the same work in a fraction of the time.

------
tofof
I read assertion after assertion and kept waiting for that 'why' from the
title.

------
Imagenuity
One big perception is that if the UI is not quite right (or worse), the code
is also not quite right (or worse). Since the UI is seen and code is unseen,
it becomes the visible representation of overall quality. So even if the code
is tight and elegant underneath a sloppy UI, it will be perceived at the
quality of the UI.

~~~
gruseom
Absolutely. To nearly everyone, the user interface _is_ the program. This
sounds like a truism but really is the opposite. It has important practical
consequences.

~~~
Chris_Newton
_To nearly everyone, the user interface_ is _the program._

I would add to that the reason I’m wary of shipping an unpolished product as
early as possible with the idea of refining it later: you only get one chance
to make a first impression.

~~~
supercoder
I think there's an important distinction between an unfinished product and an
_unpolished_ product.

To use an overused example, the iPhone was unfinished in terms of features but
what was there was incredibly polished.

------
Wintamute
Hmm. I can say with certainty that the great designers I've worked with have
never had to make requests like this. They understand the idea that all sites
should be built out of reusable components, and the visual relationships
between those components should flow across the whole site. The CSS is robust
and working site wide, the code is simple and beautiful and the design/UX is
great, everyone is working efficiently - and everything flows from it. But any
time you have to budge a button -3px, increase some front size 1px, tweak that
padding there, fiddle with the line spacing on that subheading, or satisfy
some other pixel pushing whimsy ... then the design has failed, the designer
doesn't understand the medium.

Usually these sorts of requests come from mediocre designers who feel
professionally threatened by a rapidly evolving scene and then feel the need
to create a sort fake value for their role by insisting on such things. Very
often such behaviour will come along with the sentiments expressed in OP's
article, some sort of implied idea that they have the sole understanding of
aesthetic value or what can be considered "delightful".

~~~
seanmcdirmid
I really doubt you have worked with designers at all, let along great ones.
Any designer, junior or senior, that I've worked with, won't ignore the small
stuff, and the better designers are more likely to be perfectionists.

> Usually these sorts of requests come from mediocre designers who feel
> professionally threatened by a rapidly evolving scene and then feel the need
> to create a sort fake value for their role by insisting on such things.

This is such an immature comment I don't even know how to respond. A designer
that was so deferential to developer to not sweat pixel alignment would simply
not even get hired in the design studio I've worked with.

~~~
Wintamute
You've missed my point, and resorted to ad hominem. Way to go. I'm not saying
that the little things aren't important, its great to be a perfectionist and I
think sites are absolutely built out of details by designers and developers
working in respectful partnership. But my point is that the design details
that should be obsessed over come way before the traditional pixel pushing
session at the end of the job. Things like consistent, simple and really
robust visual relationships between components and typography across devices
and viewport sizes. In my experience this is where good designers spend their
energies - and if its done well pixel pushing should not be required.

I just responded to the point you were making in a polite manner, without
calling you immature or calling your professional experience into question.
Now do you fancy having a go?

~~~
seanmcdirmid
I did not call you immature, I called your comment immature. You made your
point with an ad hominem on a whole profession of designers who care about
pixel alignments, and so I seriously doubt you have significant experience
working with designers.

> But my point is that the design details that should be obsessed over come
> way before the traditional pixel pushing session at the end of the job.
> Things like consistent, simple and really robust visual relationships
> between components and typography across devices and viewport sizes. In my
> experience this is where good designers spend their energies - and if its
> done well pixel pushing should not be required.

Pixel pushing is ALWAYS required at some point; it is unavoidable given our
current technology. A designer cannot magically come up with a generic
responsive design because developers just can't make that happen (through no
fault of their own). Take for example icon design: it is well known that
vector graphics are quite limited and bitmap icons must be generated and
manually red lined for various resolutions. That is work the designer (or
production specialist) does. Similarly, size-independent layouts are also a
pipe dream, not because the designer is incapable, but the frameworks are!
Hence, we are stuck optimizing layouts and pixel alignments for multiple sizes
manually.

tl;dr "consistent, simple and really robust visual relationships between
components and typography across devices and viewport sizes" is very often not
workable in the real world for any non-trivial design.

Hackernews is surprisingly quite anti-designer in posting sentiment.

~~~
Wintamute
Can a comment itself be immature? I'm pretty sure only a _commenter_ has the
agency to be immature, but anyway that's beside the point :)

> You made your point with an ad hominem on a whole profession of designers
> who care about pixel alignments

Nope, at no point did I ever criticise designers who care about pixel
alignments. I criticised designers who place too much value on pixel pushing
at the end of a project - for me it's often a red flag.

Admittedly where an approach involving "consistent, simple and really robust
visual relationships between components and typography across devices and
viewport sizes" works best are for projects more towards the web app end of
the spectrum, I will concede that point, but it doesn't mean the design has to
be trivial.

~~~
seanmcdirmid
Of course comments can be immature.

> I criticised designers who place too much value on pixel pushing at the end
> of a project - for me it's often a red flag.

A lot of the bugs discovered during design QA involve pixel alignment issues.
That is one of the main reason why we have design QA. Frankly, if something
worse comes out of that (like a bigger interaction design flaw), then there
are serious problems that jeopardize the project and somebody in dev or design
has royally screwed up.

> works best are for projects more towards the web app end of the spectrum, I
> will concede that point, but it doesn't mean the design has to be trivial.

Does it really work for web? Even for web, better designs are often stuck with
2 or 3 layouts to manually tune.

------
wonnage
Getting the design right is important. But it's poorly communicated. For
better or worse, programmers tend to be primadonnas who don't respond well to
being told to move a button 3px (see seivan, et. al) for no reason.

Furthermore, the exact pixel dimensions you create in photoshop rarely
translate to the browser due to screen size differences, resolutions, etc.
It's much, much more useful for designers to tell me something that describes
the relationship they have to each other than the exact dimensions (e.g,
"these elements should line up on the right" rather than "make divs 253px").
Obviously for things like spacing there's some element of eyeballing until it
feels "right", but you can and should be working with design before stuff goes
out to get those right.

So yeah, it's frustrating as a programmer to go through these nitpicky
details. But keep in mind it's frustrating because you didn't do your job of
implementing what was specified. So maybe don't complain about it in a way
that sounds like you refuse to do your job.

------
WWKong
So why should you move the button? You didn't say that. All I see from you is,
"move the button" which is up against the request from the business guy that
reads, "add the 4th option to the drop down and the client will pay us $50K
more". Want to guess what is going to make the next sprint?

------
sekasi
Honestly, I can't believe some of the responses here. 'Fix it yourself'.
'Fixing bugs is more important' and a number of other black and white missing-
the-point dravel.

Let me help. Here are a few pieces of irrefutable truths:

\- Any developer who doesn't see, or care, about attention to visual details
is a bad member of the team.

\- priorities. Of course big bugs are more important. Why would you even
mention that.

\- Good designers have their set of priorities. A good developer understands
that, and doesn't say mind numbing things like 'don't waste my time'.

\- Will all visual enhancements increase conversion rates? No. Does that mean
you're free to be sloppy? No.

\- At the end of the day, the balance between perfect code and perfect visual
design is up to the product owner. Discussion about what's more important is
pointless. It all matters.

------
gmays
I really enjoyed this article. Most of the stuff I read makes me feel guilty
for obsessing over the details. I'm a single-founder, work alone, and do the
design and development myself, so I end up moving slowly.

Now that my product is launched and fully functional I've been able to to back
and polish things as I have time. This really makes me feel a lot better about
the product. If I feel users are having a bad experience, it's frustrating to
me and I can't get it out of my head until it's fixed. I don't have the
resources to make everything perfect, but every day it gets a little bit
better.

I don't have a design or tech background, so I always thought I was just doing
things wrong (maybe still I am). This makes me feel a bit better about how I
work.

------
Wyrug
If you have good development practices in place, making a targeted build to
prototype 3px UI improvements suggested by ANY trusted team member should be
trivial and should be considered. After prototyping the change, it's possible
to evaluate whether the suggested lightweight improvement falls into the range
of essentially invisible (probably not worth the churn late-game, but fine
earlier) to actually awesome (crank a build if you can). Even lightweight
changes could break the hell out of some browsers/resolutions, so 3px is not
really "free". Hell, 1px is not free if floating elements can cause layout
changes or fixed elements can crash into adjoining ones. If you have
challenges making and evaluating suggested changes on very rapid timescales,
ANYpx is irrelevant in the scope of your other problems and you should trend
against change where possible. Also note that I said "trusted" team member -
if the team member pushing for design changes is not "trusted" that is a
separate consideration - please weight appropriately. If you break the crap
out of other areas, yeah, try the 3px at that point if it's a toss-up and the
change is orthogonal to other changes. If you pay the price of looking at
other changes, try to get the designer's suggested change tested for free.
Trust, but verify.

------
dchichkov
I think the author is right. Good, consistent design with good ergonomics
certainly makes work more pleasant and enjoyable.

And Yes. Yes. The difference that the 3px makes is incredible. So do get
yourself that extra 26" IPS monitor with extra 1920 x 1200 pixels.

I will kindly warn you though, that I do have some reservations about
mentioned 'Apple _glossy_ pixels', as although I'm currently wasting time
writing this on a pixel-perfect glossy MacBook Air, nothing frustrates me more
as are the reflections on that perfect glossy mirror. Which I can see right
now. Or the inconsistent <home>/<end>, <command>, <control>, <fn> keys, when
I'm actually working [if you need to spend significant amounts of time jumping
between Mac/Linux and working in a command line, you will understand]. Or
inability to connect two monitors to a MacBook Pro. Or how slow is the GCC on
the virtual machine on that MacBook Pro with puny 16Gb of RAM. So do take the
advice of the designer, but also keep in mind that _all that glitters is not
necessarily gold_.

~~~
enjoy-your-stay
I love working on my Mac, but the use of Cmd-Left and Cmd-Right instead of the
<home> & <end> keys really causes me lots of wtf? moments when I'm editing.

Fortunately xcode allows you to customize those keys which has made code
editing a lot more pleasant.

~~~
dchichkov
I think it is being called 'The dreaded Home Key syndrome.'

It is that cringing feeling and a moment of hesitation that one has when
pressing on these home/end (and ctrl/fn/command/alt/option/control/arrow
left/arrow right) keys.

------
zachinglis
Every once in a while this article pops up rewritten in another form.

Attention to details is fantastic, but the mark of the best designer is one
who ships. It is in fact the mark of the best artist who is pixel perfect.
This is not saying that you shouldn't be fixating on the details - but don't
let it interfere with the client's goals of actually being out there.

------
watwut
"When a product is close to launch, I become a perfectionist. Each misaligned
element or awkward interaction is like a thorn in my side. "

When a product is close to launch, I become paranoid. I do not want to do any
changes, unless critical. There will not be time for another round of
testing/regression testing. We have even whole process for that.

He is talking about team moving on other projects, which means he talks about
time very close to launch.

It is great when the designer is perfectionist. There is also a time for that
and that is NOT close to launch. You absolutely should come up with these
changes while the project is far from launch so we can time for fixing them.

You should absolutely NOT suddenly come up with tons of tiny little changes
close to release. One of those tiny little changes may break something
important and we will have no time to find out.

------
malandrew
Or you, the designer, could learn a little CSS and git and submit a pull
request with the micro-optimizations you want changed.

Every time you request changes instead of making them yourself, you are taking
away from the time they can spend delivering improvements in their area of
expertise, executable code.

~~~
goldenkey
Photoshop cowboy is a one-man band on the run

------
arghbleargh
The article actually makes pretty good suggestions despite coming off as a
little arrogant (our design tweaks will make a world of difference, if only
the developers could understand!). I think the key is to realize that the
visual design work comes last. Moving things by a few pixels here or there is
not going to make or break your product, because the purpose of your product
is to provide some sort of useful functionality and not just to look pretty
(presumably). And a lot of times it's completely subjective anyway. Get the
approximate layout and user interactions nailed down first, ignoring any
superficial flaws. Then, at the very end, I don't think the developer will
mind if you ask him or her to make one pass of tweaking a bunch of colors and
alignments.

------
hrktb
> So it’s not enough to say “it looks better this way”. Designers need to make
> a case for why the team should spend time on fit and finish.

That point is central to the post and yet not really followed IMO. Costly
changes to the UX should be justified in objective terms, e.g. consistency,
color or style matching, differenciation, focus improvement, branding,
readability... Not a "it feels better", or "it's delightful" or "I'm a
creative person, I know what's right" (<\- if it's his/her personnal project
this one is OK)

~~~
rwmj
Only one way ... higher profits.

------
tobico
I think this is often a problem of dividing responsibilities.

In order to turn a design into correct CSS, the size and position of each
element needs to be measured precisely. If the Photoshop-using designer can't
or won't do this themselves, and send through clearly specified requirements,
it falls to devs who probably aren't Photoshop experts, don't know what the
designer was thinking, and might not even have Photoshop.

A nice side effect of having clear requirements is that everyone in the team
can easily refer back to them to spot design bugs, not just the designer.

------
djyaz1200
Great article! Like many of you I have worked with great teams and bad teams.
In my experience a great UI/UX is a sign of a great team/company with a clear
focus. The designers and engineers cannot fight for whose approach is
superior, they must respect and understand each other and the user intent.
They have to communicate well and sometimes invent new options together when
their views or constraints are in conflict. This requires talent, teamwork and
a focus on excellence at a level that cannot be faked.

------
Houshalter
Well this is overkill, but if you really care about the optimal design, I
wonder if you could optimize them with something like a genetic algorithm or
some kind of machine learning. Google did this to find the optimal shade of
blue for their logo. There is even a site designed entirely like this:
[http://www.metamorphosite.com/about](http://www.metamorphosite.com/about)

IMO it really isn't worth the time though.

------
zobzu
for the record i really dislike the sidebar of that site. ;-)

~~~
jbeja
Though that i was the the only one, that is actualy one thing that need some
px to the right.

------
brandonhsiao
One more argument for mapping each job to one person. A-level players don't
need to be managed and shouldn't have to ask anyone for approval. The non-
designers should trust the designers to worry about the right details. If a
designer thinks moving a button 3px to the left is important, then it's
important _whether or not everyone else understands why_.

------
TranceMan
I think the article should have shown the whole page for context.

My front end UIs are limited to bootstrap - it works :) - but if one/two/three
button[s] are not aligned the same as all the others - I will focus on that
rather than the data. My train of thought is gone.

------
Pxtl
Why is this an argument between you and the engineers? Get latest, make the
change, test it as best you can, commit it with a descriptive comment, and
it'll go to QA for the next deployment.

What, you want somebody to do it _for you_?

------
al2o3cr
Better title: "Why Your Designers Should Know Git"

------
brimstedt
he has a point and i like perfected ux too, but as a programmer im unable to
achieve perfected UIs :)

anyway, there is also "good enough" and most likely 3px wont matter any more
than refactoring a perfectly working class into a perfectly working class with
perfect code...

------
seivan
This article pisses me off something immensely. How about you learn to fucking
code your own design?

'Yet we’re at the mercy of our teams. We can design beautiful, intricate,
delightful details — but we can’t build, test, and deploy them all.'

No shit, so how about you stop being one of those lazy-ass photoshop goons who
play fucking color-the-button on dribble all day long and actually learn to
code your own fucking interface, either in Cocoa, JS, CSS or whatever.

This ain't the 80's no more. Software Engineers that work on front-facing
stuff can and have learned design. Not just graphical design but even
interaction design and designing slick user experiences.

Though I can't speak for all platforms, most Web & iOS developers I've met can
do all that photoshop pixel-perfection bullshit _AND_ code the interface.

Which makes me hard to think why even have these photoshop-cowboys.

'We can design beautiful, intricate, delightful details'

The .psd file or your design ideas isn't worth anything. Fuck you if you call
yourself a designer and can't work on the final medium.

EDIT: Pardon the tone.

~~~
grownseed
Tone aside, I can't help but agree. My previous job (web shop) hired
supposedly "rockstar" designers on several occasions, and the results were
frustrating, time-consuming and in the end, largely worthless.

What did not help was that those people had "print design" backgrounds, my
bosses loved the rendered (hard) designs, and not having any design or
development knowledge themselves, these sorts of ludicrous standards were
somehow becoming the norm.

So we ended up spending as much time trying to render some goddamn rounded
corner with a gradient for all browsers than we did implementing actual
functionality, generally causing us to cut corners all around (no pun
intended)...

In my opinion, a good designer should know the limitations of the tools
according to context and resources. As far as I know, you never hear of car
designers asking the engineers to somehow find enough space for the engine, or
an architect telling you that the plumber will have to somehow figure out
where to put the pipes in his 36.3cm thick walls.

This is 2014 and I don't think there's a place for single-skill design queens
any longer. As a developer I have to learn a new language pretty much every 6
months, and generally speaking new technologies far more often. So surely, the
argument that "true" designers should not have to learn CSS (or related) is
moot and let's be honest, arrogant.

To me, it's very much like the idea that politics or philosophy by themselves
are vacuous. The world isn't waiting for your design like it's a god-send,
you're making the design because you were asked to, by real people with real
needs, all of whom, designer included, have to put food on the table.

~~~
samatman
Where architecture is concerned this is normally true, but the exceptions are
interesting/illustrative. When Frank Gehry was designing the Guggenheim
Bilbao, he took stiff cloth and folded it into the final shape. Actually,
y'know, making the building was someone else's problem.

~~~
mirchibajji
This is the equivalent of implementing the design in Flash :)

------
throwaway420
* Obsessing over tiny little details is the mark of a great designer. However, that doesn't mean that you should always be doing this. Say that you're launching a startup on a limited budget, for example. If you're spending an inordinate amount of time trying to decide between two slightly different shades of purple, or figuring out whether some border should be 1 or 2 pixels thick, odds are you're misusing your resources. There's a certain time and place to obsess over certain types of details - many startups would be better served obsessing over finding paying customers and refining their business model rather than spending lots of effort on some of this stuff.

* For the record, while this person obviously seems talented, I really dislike how the site jarringly starts shifting the content you're reading over to the side a second after load. If he wants to write about tiny little design details, I'd argue that's one of the most annoying things that he's missed.

------
flibertgibit
Great post. I noticed I read very little about usability and only about
design. I'm assuming that the OP, Braden, assumes that we understand that
usability is integral to design. The reason I say this is that I've heard and
seen designers spend lots of time on something that most of the techs/devs
said WTF to after they were done- one carousel, crappy menu, and pointless
site after the next. That was an in-house design team working for a large
university, btw, so the main problem was that the administration was the
customer, not the primary users, which were students, university employees,
prospective students, and parents of prospective students. And their attempt
at usability studies involved a small number of students passing in the
student union that got snickers bars in exchange for telling them what they
thought. And no AB testing ever done.

------
jbeja
UI design obsession hit as hard as software design obsession, both are equally
valid and should be respected. In others words if a designer tell you to move
a button 3px to the left, then you should take in consideration his gust and
ask them politely why they should. The same could apply if a more experience
college tell you that this method don't belong to that class or that function
is doing too much. Just respect each other and be on peace for the sake of the
project.

------
seivan
Lets call them what they really are. Photoshop designer. That pretty much
defines you.

