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.
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.
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.
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.
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.
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.
Those are fundamentals of design but a) they're hardly universal, and b) they only serve to anchor the debate.
A person with that list can't answer you which color the buttons should be, or say, whether a certain button is more like a confirm, info or cancel. They don't tell you how wide is too wide, or whether the hero needs to be above or below this particular content. It's a good starting point, but hardly anyone will be satisfied to be told, "well, the golden ratio is preserved when we make the content area 700 pixels wide" -- again, in the end these discussions always come down to trusting a person's taste.
I've worked with plenty of properly trained designers, whatever is supposed to be proper.
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.
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".
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.
heh. methinks a programmer who thinks programming is objective and not subjective has the equivalent professional experience in the field as a designer who doesn't know the difference between design and art so designs subjectively.
Engineer/Dev will come to me on a regular basis to "use framework X", that code is module Y is shit because and there is a more optimal version of the algorithm. Most of the time, there is not objective reason other than "I have used that before and I liked it", "micro-benchmark say so, but I have not looked in this case if there is any interest for us".
Client want our application to produce an incorrect file, having forgotten that some bloke in their department is correcting by hand all the incorrect file of the old application.
Manager want you to do a daily timesheet to properly track client billing despite the fact that your team is working full time for a single client.
Client/Manager/Other Developer regularly ask for rubbish reason all the time, why would the Designer be any different ?
They may have a good reason this time, just spend 2 min to explain them.
> 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.
The difference being that the developer makings his own changes as he sees the problem, not asking someone else to make the changes, whereas the designer just asks someone else to make an arbitrary change. If the developer is asking someone else to make a few lines of changes, he better gives a good justification.
So a developer is permitted to make arbitrary changes to the design at his whim with no justification, because he/she is doing the actual work. Because design is not actual work? But the designer, with years of experience, research, university studies and so on, cannot request to reverse that arbitrary change?
I mean, it's division of roles. does the developer want to be a designer too? Does the developer want to justify their choice of algorithms to the designer?
Doesn't this seem one sided to expect the designer to justify every choice, but the developer answers to no-one?
The point is when you ask someone else to do the work for you, you need to give more justification than you are doing it yourself because in software development pretty much everyone has their plate full or overflowed, and your adding of more work on them would need to be prioritized against pushing something else off. Of course you need to justify your change that is important enough to push off some of other work.
If you are doing the change in HTML/CSS/Javascript or whatever yourself, go right ahead. Just make sure you don't break something else.
Likewise if there's change the developer is asking the designer to make, the developer better makes a good case for it. What if I tell you to remove the color red and blue in your design. Just do it. Don't ask why. You would be annoyed, too. And when you question, I told you, oh well, based on my years of training and experience, color red and blue run slowly in this algorithm.
I think what annoys most people here is that the designer thinks his changes are the most important ones and have to be made. There are millions other things the engineers need to worry about to make the product work. If the database is corrupting, moving 3 pixels to the left is not important. What the engineers asking is the justification for the change so that it can be weighed against other priorities. Isn't that so hard to do?
Just for the record, in environments where devs have to get their changes validated in a way or another (i.e. get it past the test team, release to prod etc.), they will get a resounding NO, if they try to change some code just for the sake of it (even if it's called "refactoring") or things they can't argue to be valuable (depending on where you are, fixing a minor bug might not be a good enough reason for changes).
There's no double standards, basically anyone has to justify spending other people's time.
> 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?
You are right, they often have good reason, and can make the case by explaining that. Of course, they often to not have a good reason beyond spacing, it looks better, it is too crowded, or it is not crowded enough.
Isn't it unreasonable to expect that every design decision be based on logic? Human beings have two brain hemispheres. TWO WHOLE BRAIN HEMISPHERES. a right lobe and a left lobe. The right lobe is JUST AS BIG and complicated as the left lobe, in which our logic and reasoning abilities are based.
But in our culture, especially in development culture, for some reason any decision based on a process in the right hemisphere is valued far less. We call it "subjective" even though it isn't. It's the same processes that every human brain does in much the same way. This is why optical illusions can work. They work much the same way for every person, and the reasons they work are not based on logic. They're based on physical, biological processes in our visual processing systems. It's not a "logical" or "rational" process. It's a visual process.
But if a designer says that spacing is going to cause a problem, it's not valuable input because there is no "logical" reason behind it. That's not logical!
All of these statements might be true, but they neither imply nor advance one another. They are all non sequiturs. Also, there is less to the left/right brain thing than most people seem to think.
I can only guess that you just didn't read it, or don't understand it, because you're 100% wrong. Not just wrong, but ironically wrong- you're explicitly proving my point that the only thing you value is logic and reason. Which is ridiculous because our brains do a lot more than just logic and reason.
As for the left/right thing, I know that- strictly speaking, there isn't really that much of a left-right separation of concerns in the brain. It doesn't matter for my point though. It's just a metaphor for the easily demonstrable fact that brains have functions other than logic that are just as useful and important to satisfy.
Actually, I think moving a button 3px anywhere could be easily justified by a combination of Fitts' law and research on how humans perceive the button as something actionable and distinct from its surroundings.
That said, I'm a software engineer with a semi-formal training in user experience and moved from front-end design initially through Zeldman/CSS of 2003 to backend and mobile (and more formal CS concepts in university).
Design matters as much as the code you write. Sadly, driving technical change in either is tougher than it looks. And we won't even get into the misinterpretations possible when people assume something can be done pixel-perfect or was misread as pixel perfect when that wasn't the intent. Working together productively is the soft skill worth developing for both sides of the art/science divide.
Arrrrrrrrgh. Engineers. If I were to say "I had a design bug" and leave it at that, they'd do it. Even better, if I were to say "I resolved some design flow lag" they'd even smile. Engineers can't stand lag (and that's exactly what the fix is about).
As for PS mocks - stuff is entirely different on the screen. And the 3px difference could have been a dev mistake and the designer is correcting them.
I can't tell how serious you are, but no, please don't call it "design flow lag". Speaking for myself, and I suspect most engineers, stringing a bunch of weird words together to say "I messed up" or "you messed up" is just going to piss me off.
There's something sad about that division of people in engineers and designers. For any application that pretends to be worth anything, 'engineers' also participate to the design phase from an early stage, and 'designers' have sufficient knowledge of the basic engineering issues to take into account.
IMO the job title 'designer' is really void of meaning and should go away, but I'm not holding my breath.
Perpetuating the "designers are fearies and engineers are robots" stereotype doesn't really help in any way
Here's another one. Engineers also can't stand broken flow. If you'd ask me "hey, can you move that button by 3px?", that's pretty much equivalent to asking me - "hey, can I waste some of your time?". But if it actually fixes lag or broken flow, this is significant. And any good engineer will be happy to help that fixed.
Where I work, pixel alignments and gaps are generally explicitly indicated in the design spec. If the code is not following the spec, its definitely the code's fault. If the spec is found to be wrong after implementation, then first fix the spec then ask for the code to be synced.
There is a whole class of people who are good at red lining and doing design QA; in a larger company, it might not even be the designer, but the design QA engineer, submitting the bug report.
I guess the 3px was more a rhetoric to drive home the more important point that design (UX and UI) matter. As has already been pointed out by someone in the this discussion, if a designer is asking you to more "3px", it is to align that element with other stuff on that page.
The larger point that it lends credibility to your product is mostly overlooked. I have seen in my consulting experience that taking care of small UX flow and info flow issues has led to veritable gains by companies.
Going by the discussion, it seems there is a good opportunity in the space of "engineering-design collaboration" :)
Personally (I don't speak for all devs, although some people on HN certainly seem to think they do...), the issue I have is that I rarely receive a response as clear cut as the one you propose.
"if a designer is asking you to more "3px", it is to align that element with other stuff on that page."
If they want elements aligned, or snapped to a grid, or whatever - sure, there is justification there. It's when I'm handed design changes with no justification that I get riled.
But yeah, at the end of the day engineers and designers really need to have a few more beers together.
You do realize that the user does not think in CPU cycles or FPS, right? Just as the goal of lowering CPU usage or increasing FPS is to improve the emotional experience the product user, so is making sure that the visual elements are properly aligned.
As the engineer, you have been staring at the product for hours at a time and are comfortable with it, perhaps even one with it. The consumer on the other hand is likely going to spend at most a few minutes before making a purchasing decision about it, or simply hitting the back button. Thus, it is important to enchant the user from the get go.
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.