26 ms·

Why you should move that button 3px to the left

119 points by axelbouaziz 13y ago

malandrew 13y ago
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 13y ago
  Photoshop cowboy is a one-man band on the run
brimstedt 13y ago
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...
rmetzler 13y ago
Maybe designers should learn a little bit of CSS and git and just fix the pixels.
- lincolnq 13y ago
  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.
- cozuya 13y ago
  Maybe they should hire front end developers that can make a website that looks exactly like the design. Essentially, that is the entire job!
- deleted 13y ago
  [deleted]
valtron 13y ago
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 13y ago
  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.
  - Chris_Newton 13y ago
    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? Why would either of those things be a problem? Attention to detail is attention to detail at any scale. It’s true that at scales smaller than anyone would normally notice there can be a difference between a clean optical alignment and a “perfect” mathematical one. This is a challenge that folks like font designers and artists working on icons often have to face. If you zoom in dramatically (say 5x or 10x, not 120%), these details would probably look slightly off. However, at the kind of scale we’re using for examples here, zooming in will only exaggerate careless flaws like having things misaligned by a pixel or using the same border-radius for nested elements where concentricity of the rounded corners was intended. A well designed page will continue to look clean and tidy at larger scales, and it won’t mysteriously break just because someone zoomed or had different font preferences.
    - the_hangman 13y ago
      I'm not sure how familiar you are with the zoom functions on web browsers, but zooming in on many web pages can easily destroy the design. This is especially true when using a lot of media queries in your CSS and when using absolute units to position and size elements in your CSS (e.g. using px's for your base font size instead of em's or %).
tofof 13y ago
I read assertion after assertion and kept waiting for that 'why' from the title.
zobzu 13y ago
for the record i really dislike the sidebar of that site. ;-)
- jbeja 13y ago
  Though that i was the the only one, that is actualy one thing that need some px to the right.
Imagenuity 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      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.
gruseom 13y ago
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 13y ago
  ...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 13y ago
    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.
TranceMan 13y ago
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.
nahname 13y ago
>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 13y ago
  Some companies have rules that actually do prevent people from just diving on and doing whatever they want with the code.
  - dredmorbius 13y ago
    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 13y ago
      s/ate/are/ damn you mobile
al2o3cr 13y ago
Better title: "Why Your Designers Should Know Git"
aresant 13y ago
"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=0 http://www.nytimes.com/2009/03/01/business/01marissa.html?_r...
throwaway420 13y ago
* 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.
brandonhsiao 13y ago
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.
dchichkov 13y ago
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 13y ago
  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 13y ago
    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.
crazygringo 13y ago
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.
- seivan 13y ago
  'I'm having a tougher and tougher time appreciating these photoshop cowboys. ' Give me a break. That's the default these days. I've yet to met iOS developers or front-end engineers who can't design. We don't need these photoshop goons anymore.
  - goldenkey 13y ago
    Having to explain to your project manager that their Photoshop cowboy is out of touch, and turning PSDs into code is more work than simply designing things yourself is a virtue I've never goated. I hate Photoshop cowboys
    - seivan 13y ago
      I could, if I was given the opportunity and the time.
d0m 13y ago
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.
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 ago
  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" :)
  - 13y ago
seivan 13y ago
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.
- exizt88 13y ago
  This is really wrong, and the arrogant tone doesn't help a bit. The truth is that a designer who spends 100% of his time doing design will definitely be better at design than a designer who spends 50% time designing and 50% time developing. These are two very different skill sets (even though their fundamentals may be closer). Anyway, a good designer's decision to move something 3px to the left should be respected (because he knows better - he's a good designer). And moving a button 3px to the left shouldn't be a problem for any self-respecting developer.
  - seivan 13y ago
    You don't think the engineers platform specific knowledge will have any impact what so ever? And where do you draw the line between engineering and designing? An engineer can design their design as they go along and iterate on it. Recently I've been doing my iOS design through SCSS and it helps having sizes, gradients and colors as variables, fonts as mixins and the ability to change them at runtime. Does that count as designing or engineering? Your truth is not the truth, it's more like bullshit. I don't specifically know what the truth is - but I do know that I'd pick an engineer that can design over a designer 10/10 times. Regardless of your 'truth'.
zachinglis 13y ago
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.
gmays 13y ago
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.
WWKong 13y ago
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?
hrktb 13y ago
> 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 13y ago
  Only one way ... higher profits.
wonnage 13y ago
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.
sekasi 13y ago
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.
tobico 13y ago
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.
underwater 13y ago
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 13y ago
  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.
ryandrake 13y ago
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.
- robotys 13y ago
  This comment win. What frustrate developers/engineers are their code changes need to pass the test immediately. The consequences is immediate. Compare it to design consequences, it seems like an eternity, especially if the design changes never have any test/measure to get passed. Designer can blame developers when dev cant code their design which is so delightful the sales will improve. But developers cannot blame designer when the sales does not come through from the changes. Sales manager do. There is test for design and it was called 'split testing'. Unfortunately it is marketers/sales job to come up with the test, not designers. By these rules, designers should be in sales team instead of product team!
- kaishiro 13y ago
  Yes, thank you. Nailed it.
- arrrg 13y ago
  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.
Pxtl 13y ago
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?
arghbleargh 13y ago
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.
Wintamute 13y ago
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 13y ago
  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 13y ago
    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?
Houshalter 13y ago
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.
djyaz1200 13y ago
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.
flibertgibit 13y ago
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 13y ago
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.
watwut 13y ago
"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.
Wyrug 13y ago
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.
seivan 13y ago
Lets call them what they really are. Photoshop designer. That pretty much defines you.

119 points by axelbouaziz 13y ago

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 13y ago
Photoshop cowboy is a one-man band on the run

brimstedt 13y ago

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...

rmetzler 13y ago

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

lincolnq 13y ago
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.
cozuya 13y ago
Maybe they should hire front end developers that can make a website that looks exactly like the design. Essentially, that is the entire job!
deleted 13y ago
[deleted]

valtron 13y ago

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 13y ago
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.
- Chris_Newton 13y ago
  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? Why would either of those things be a problem? Attention to detail is attention to detail at any scale. It’s true that at scales smaller than anyone would normally notice there can be a difference between a clean optical alignment and a “perfect” mathematical one. This is a challenge that folks like font designers and artists working on icons often have to face. If you zoom in dramatically (say 5x or 10x, not 120%), these details would probably look slightly off. However, at the kind of scale we’re using for examples here, zooming in will only exaggerate careless flaws like having things misaligned by a pixel or using the same border-radius for nested elements where concentricity of the rounded corners was intended. A well designed page will continue to look clean and tidy at larger scales, and it won’t mysteriously break just because someone zoomed or had different font preferences.
  - the_hangman 13y ago
    I'm not sure how familiar you are with the zoom functions on web browsers, but zooming in on many web pages can easily destroy the design. This is especially true when using a lot of media queries in your CSS and when using absolute units to position and size elements in your CSS (e.g. using px's for your base font size instead of em's or %).

tofof 13y ago

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

zobzu 13y ago

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

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

Imagenuity 13y ago

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 13y ago
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 13y ago
  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 13y ago
    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.

gruseom 13y ago

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 13y ago
...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 13y ago
  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.

TranceMan 13y ago

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.

nahname 13y ago

>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 13y ago
Some companies have rules that actually do prevent people from just diving on and doing whatever they want with the code.
- dredmorbius 13y ago
  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 13y ago
    s/ate/are/ damn you mobile

al2o3cr 13y ago

Better title: "Why Your Designers Should Know Git"

aresant 13y ago

"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=0 http://www.nytimes.com/2009/03/01/business/01marissa.html?_r...

throwaway420 13y ago

* 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.

brandonhsiao 13y ago

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.

dchichkov 13y ago

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 13y ago
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 13y ago
  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.

crazygringo 13y ago

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.

seivan 13y ago
'I'm having a tougher and tougher time appreciating these photoshop cowboys. ' Give me a break. That's the default these days. I've yet to met iOS developers or front-end engineers who can't design. We don't need these photoshop goons anymore.
- goldenkey 13y ago
  Having to explain to your project manager that their Photoshop cowboy is out of touch, and turning PSDs into code is more work than simply designing things yourself is a virtue I've never goated. I hate Photoshop cowboys
  - seivan 13y ago
    I could, if I was given the opportunity and the time.

d0m 13y ago

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.

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 ago
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" :)
- 13y ago

seivan 13y ago

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.

exizt88 13y ago
This is really wrong, and the arrogant tone doesn't help a bit. The truth is that a designer who spends 100% of his time doing design will definitely be better at design than a designer who spends 50% time designing and 50% time developing. These are two very different skill sets (even though their fundamentals may be closer). Anyway, a good designer's decision to move something 3px to the left should be respected (because he knows better - he's a good designer). And moving a button 3px to the left shouldn't be a problem for any self-respecting developer.
- seivan 13y ago
  You don't think the engineers platform specific knowledge will have any impact what so ever? And where do you draw the line between engineering and designing? An engineer can design their design as they go along and iterate on it. Recently I've been doing my iOS design through SCSS and it helps having sizes, gradients and colors as variables, fonts as mixins and the ability to change them at runtime. Does that count as designing or engineering? Your truth is not the truth, it's more like bullshit. I don't specifically know what the truth is - but I do know that I'd pick an engineer that can design over a designer 10/10 times. Regardless of your 'truth'.

zachinglis 13y ago

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.

gmays 13y ago

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.

WWKong 13y ago

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?

hrktb 13y ago

> 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 13y ago
Only one way ... higher profits.

wonnage 13y ago

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.

sekasi 13y ago

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.

tobico 13y ago

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.

underwater 13y ago

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 13y ago
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.

ryandrake 13y ago

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.

robotys 13y ago
This comment win. What frustrate developers/engineers are their code changes need to pass the test immediately. The consequences is immediate. Compare it to design consequences, it seems like an eternity, especially if the design changes never have any test/measure to get passed. Designer can blame developers when dev cant code their design which is so delightful the sales will improve. But developers cannot blame designer when the sales does not come through from the changes. Sales manager do. There is test for design and it was called 'split testing'. Unfortunately it is marketers/sales job to come up with the test, not designers. By these rules, designers should be in sales team instead of product team!
kaishiro 13y ago
Yes, thank you. Nailed it.
arrrg 13y ago
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.

Pxtl 13y ago

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?

arghbleargh 13y ago

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.

Wintamute 13y ago

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 13y ago
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 13y ago
  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?

Houshalter 13y ago

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.

djyaz1200 13y ago

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.

flibertgibit 13y ago

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 13y ago

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.

watwut 13y ago

"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.

Wyrug 13y ago

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.

seivan 13y ago

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