7 ms·
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"
by sxp 13y ago
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.
- varunsharma13 13y agoI 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" :)
- kaishiro 13y agoPersonally (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.
- radley 13y agoArrrrrrrrgh. 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. Anyways, designers: just call it design flow lag.
- dchichkov 13y agoHere'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.
- seanmcdirmid 13y agoWhere 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.
- hrktb 13y agoThere'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
- andrewflnr 13y agoI 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.
- Chris_Newton 13y agoAnd 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.
- ricardobeat 13y agoThat last paragraph is a fairly accurate description of work at decadent BigCos.
- sxp 13y agoWhy 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.
- pazimzadeh 13y agoYou 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.
- lstamour 13y agoActually, 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.