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.
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.
The web was supposed to free us from the over-design of glossy magazines and Madison Avenue bullshit. Content was supposed to be king. So forgive us if we are a little bitter that it turned into just another high gloss magazine.
> Does the designer know how to use git and commit properly? Do they know on what branch? Understand the deployment schedule? Perform browser testing? Are they part of code reviews? Do they understand whether that rule is used by just that component, or just that page, or if it will affect code elsewhere?
If he doesn't, find one who does. A web-designer who doesn't understand code is like a fashion designer who can't sew.
> A web-designer who doesn't understand code is like a fashion designer who can't sew.
Except there are successful fashion designers who rarely if at all sew, just like there are successful interactive designers who rarely if at all code.
Do I think knowing how to code typically makes a designer a better designer than others? Yes. Do I think it's always that way? Hell no.
You can have a pure designer who doesn't understand code, but can follow the spec for interfacing with the frontend devs (give them a PSD). Just as those frontend devs might not understand how to best design a database-driven backend, but they can follow the spec for interfacing with it (REST calls through xhr). And those backend devs don't have to know about frontend application frameworks, they can follow the spec for interfacing (REST endpoints).
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
First of all, I think it's vital for web designers to know HTML and CSS. Even if they don't know it well, they should still know it enough to get the basics. The reason I strongly believe this is that the web is an interactive medium. It's dynamic, it morphs, it needs to provide feedback, and it needs to be interacted with. You get none of that when you create a photoshop image. You don't have to account for users having different display sizes, or the data changing, or the UI elements reacting to context and helping guide the user. It's important to have some intimate familiarity with the medium, beyond just using it, to properly build for it.
Making something pretty might be good enough for a splash page, but when it comes to actual UI, it just doesn't cut it. I've run into all these problems over and over again with different designers who won't touch or even look at code. Their designs just aren't flexible or nuanced enough to cover all the dynamic aspects of the web. They might look great, but they are often fundamentally broken.
Knowing CSS also helps you create more consistent web experiences. CSS encourages patterns and re-use, and having consistent pages and UI components also lead to better more familiar experiences. I've been given page designs before where every page had slightly different typography or buttons because they were doing everything in photoshop, instead of something that's actually designed for layout, like indesign.
I think all web designers should be able to conceptually do the tasks that are brought up in the article. Things like moving a button a few pixels, or changing colors, and little things like that are easy to do, and can be taught in a few minutes. I'm not talking about writing new CSS, I'm just talking about tweaking existing properties. Subtracting a few pixels from `margin-left` is easy.
Many print designers might not be able to work a printing press, but they still have a concept of how it works, to the point that their terminology like "leading" actually comes from the inner workings of the printing press.
You bring up a great point that it can be much harder to integrate designers into a development environment than it is when they're writing code for a blog or portfolio. Maybe your CSS is messy, and it's hard to find where styles are actually coming from. However, the time needed to do tiny design tweaks is not trivial and adds up. It can easily be worth it to refactor your code in some cases, both for developer sanity and for better collaboration. Also, testing tweaks in chrome's inspector is not a colossal task and can be taught to designers without too much difficulty.
As for keeping the code clean? If they aren't competent enough to contribute directly to the code base, absolutely do not give them access to origin master! Really, nobody should. Once your team goes beyond just a few people, code review is a must for everything, not just designer contributions.
Now git? Git sucks for non developers. Hell, it even sucks for developers too while you're still learning it. But there are ways around it that are user friendly enough for not super technical designers to still be able to contribute and not destroy the code base. If you use GitHub, have them fork the code base, and then they can use the built in editor to make file changes and add commits directly. After that, you click the "pull requests" tab, then it shows you your changes, and you just click "create pull request". Then it goes to a developer who can then test and approve the changes without any danger to the code base. There's a bit of an initial time investment to get someone not very technical to that point, but I think it's worth it.
Also, it's ultimately demeaning and humiliating to have a developer who has his head thinking about tough programming and architectural challenges to have to break out of his flow to change the value `5px` to `2px`. Menial tasks like that are inevitable in a real world code base, but we should be actively trying to get rid of them.
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.
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.
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!
No, but I just checked a few of the sites we made and none break from ctrl+ (regarding this: I've never seen a non-tech person, i.e. 99% of traffic for the sites, use shortcuts in the first place); they also look consistent between _modern_ browsers; and how often do people load their own fonts? Is the designer responsible that a site becomes unusable under Wingdings? (Sorry for the strawman.)
That being said, when a designer says things like "move this button 3px to the left" they usually mean things like "move this button so its right edge aligns with the right edge of the content below, which got shifted because we added padding-right." So the original request gets implemented as what he _wants_ rather than what he asked for.
> Is the designer responsible that a site becomes unusable under Wingdings? (Sorry for the strawman.)
Rather than apologize for making a strawman, how about we not make one in the first place? Nobody's talking about dingbat fonts from the 90s - GP is talking about usability today.
> No, but I just checked a few of the sites we made and none break from ctrl+
I'm glad your team has thought ahead, but I can assure you that many have not.
I can't count the number of sites that I've seen that would be completely unusable for people reliant solely on mobile devices (used as primary computing devices in the developing world), for people who rely on screen readers (blind and otherwise disabled people exist too!) - I could go on and on.
The common rebuttal I hear to this is that "the average user doesn't care about this", and the website isn't designed for "edge cases", which always makes me cringe. The wheelchair ramp at your storefront may not be used by your "average" customer, but that doesn't mean you shouldn't have one, even if the law didn't require you to[0].
Amusingly, in many cases, the sites that are the best-suited for a range of devices (desktops, tablets, phones) and clients[1] are the ones that look like they stepped out of the late 1990s.
[1] Take a minute and check if your site works in Lynx. If not, there's a very good chance your site is inaccessible to visually impaired people (yes, Lynx and similar browsers are still used by people with disabilities today!).
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.
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 %).
I'm not sure how familiar you are with the zoom functions on web browsers
I’m a professional software and web developer, and I currently build web-based user interfaces for a living.
but zooming in on many web pages can easily destroy the design
Sorry, but that’s simply not true if you have any idea at all what you’re doing. The tools to support designs that follow the original intent but are flexible enough not to break just because someone has different default fonts or zoom levels have been around for many years, they still work as well as they ever did, and they are entirely compatible with the more adaptive/responsive designs we often use today.
(e.g. using px's for your base font size instead of em's or %)
These days, it’s more likely to be the other way around IME.
Too many people still rely on received wisdom from the days when browser zooming didn’t adjust the whole page, as all major browsers now do. The original arguments for avoiding px-based font sizes were about allowing users to configure their preferred size in their browser preferences and have web sites respect it instead of overriding it. Today the default font specified by most sites is larger than it used to be (a good thing, up to a point) and if that doesn’t fit the user’s needs then every modern browser will scale it up when the page is zoomed.
Too many people are also making trendy design decisions under the banner of “mobile first” that result in a poor user experience on desktop/laptop systems (or even, ironically, on tablets). Consequently, we get silly things like specifying 30px thin fonts and main page widths/margins as percentages with no other limits, which probably look awesome on the designer’s chosen development device(s) but unfortunately look terrible and can’t be fixed using the usual browser adjustments on much larger and/or smaller screens.
>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.
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.
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.
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!
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.
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.
...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.
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.
Never use the word 'just' when talking to developers, frequently apparently simple things have huge ramifications
Sometimes that is true, and that is so whether you’re talking about changing a design or changing the underlying implementation, and whether you are talking about web design/development or software development more generally.
Having said that, if a designer can’t request and a developer can’t implement trivial changes that really are as simple as shifting something by 3px, most of the times that means at least one of the following is true:
1. The person who implemented the previous version wasn’t very good.
2. The person who implemented the previous version was pressured to take short cuts in order to hit time/money targets and produced work that wasn’t very good.
3. There is some more general problem with the development process that means a designer requesting a trivial change and a developer then making it are expensive when they shouldn’t be.
Obviously there could be exceptions where that 3px change has much wider implications for the overall layout, but I don’t think those cases are really what any of us are talking about here.
The point is that if you use the word 'just' you're saying that you already know that the change is trivial. Perhaps it is, perhaps it isn't. Show respect to the person who will implement it by letting them say whether its trivial or not.
It's absolutely true that moving a button 3px should be trivial, but it's also true that things are often not as they should be.
I agree with your fundamental point that making the assumptions about what colleagues will have to do can be dangerous, though I would still challenge your earlier suggestion that apparently simple things “frequently” have huge ramifications. It’s sensible and polite to acknowledge the possibility, but if trivial-seeming changes are getting push back more than occasionally, IME that probably indicates a more serious underlying problem with how the project is being built.
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.
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.
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.
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.
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".
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.
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?
I did not call you immature, I called your comment immature. You made your point with an ad hominem on a whole profession of designers who care about pixel alignments, and so I seriously doubt you have significant experience working with designers.
> But my point is that the design details that should be obsessed over come way before the traditional pixel pushing session at the end of the job. Things like consistent, simple and really robust visual relationships between components and typography across devices and viewport sizes. In my experience this is where good designers spend their energies - and if its done well pixel pushing should not be required.
Pixel pushing is ALWAYS required at some point; it is unavoidable given our current technology. A designer cannot magically come up with a generic responsive design because developers just can't make that happen (through no fault of their own). Take for example icon design: it is well known that vector graphics are quite limited and bitmap icons must be generated and manually red lined for various resolutions. That is work the designer (or production specialist) does. Similarly, size-independent layouts are also a pipe dream, not because the designer is incapable, but the frameworks are! Hence, we are stuck optimizing layouts and pixel alignments for multiple sizes manually.
tl;dr "consistent, simple and really robust visual relationships between components and typography across devices and viewport sizes" is very often not workable in the real world for any non-trivial design.
Hackernews is surprisingly quite anti-designer in posting sentiment.
Can a comment itself be immature? I'm pretty sure only a commenter has the agency to be immature, but anyway that's beside the point :)
> You made your point with an ad hominem on a whole profession of designers who care about pixel alignments
Nope, at no point did I ever criticise designers who care about pixel alignments. I criticised designers who place too much value on pixel pushing at the end of a project - for me it's often a red flag.
Admittedly where an approach involving "consistent, simple and really robust visual relationships between components and typography across devices and viewport sizes" works best are for projects more towards the web app end of the spectrum, I will concede that point, but it doesn't mean the design has to be trivial.
> I criticised designers who place too much value on pixel pushing at the end of a project - for me it's often a red flag.
A lot of the bugs discovered during design QA involve pixel alignment issues. That is one of the main reason why we have design QA. Frankly, if something worse comes out of that (like a bigger interaction design flaw), then there are serious problems that jeopardize the project and somebody in dev or design has royally screwed up.
> works best are for projects more towards the web app end of the spectrum, I will concede that point, but it doesn't mean the design has to be trivial.
Does it really work for web? Even for web, better designs are often stuck with 2 or 3 layouts to manually tune.
> I'm pretty sure only a commenter has the agency to be immature
The commentator has agency, but by their human nature are complex enough that their individual actions - be they mature, immature, or whatever else - are rarely adequate to judge the commentator as a whole.
The most mature among us still has agency to make immature comments. The most immature among us still has agency to make mature comments. Labeling the act is not labeling the actor.
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.
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?
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.
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.
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.
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.
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.
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.
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.
"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.
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.
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.
> 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)
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.
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.
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
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.
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.
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.
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...
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.
Tone aside, I can't help but agree. My previous job (web shop) hired supposedly "rockstar" designers on several occasions, and the results were frustrating, time-consuming and in the end, largely worthless.
What did not help was that those people had "print design" backgrounds, my bosses loved the rendered (hard) designs, and not having any design or development knowledge themselves, these sorts of ludicrous standards were somehow becoming the norm.
So we ended up spending as much time trying to render some goddamn rounded corner with a gradient for all browsers than we did implementing actual functionality, generally causing us to cut corners all around (no pun intended)...
In my opinion, a good designer should know the limitations of the tools according to context and resources. As far as I know, you never hear of car designers asking the engineers to somehow find enough space for the engine, or an architect telling you that the plumber will have to somehow figure out where to put the pipes in his 36.3cm thick walls.
This is 2014 and I don't think there's a place for single-skill design queens any longer. As a developer I have to learn a new language pretty much every 6 months, and generally speaking new technologies far more often. So surely, the argument that "true" designers should not have to learn CSS (or related) is moot and let's be honest, arrogant.
To me, it's very much like the idea that politics or philosophy by themselves are vacuous. The world isn't waiting for your design like it's a god-send, you're making the design because you were asked to, by real people with real needs, all of whom, designer included, have to put food on the table.
The age of the non developing designer is drawing to a close; Responsive design alone may be their undoing and good riddance I say, they've been designing to their mediums weaknesses for too long. So in awe are they of their own perceived brilliance that the strengths are a total mystery to them.
I cut my teeth as a print designer and the same old complaints were there then. The designer wants an 8 page gatefold as a single page can't possibly be expected to bear the weight of their genius. Nothing less than spot varnish and gold foil will do, costs and timeframe so be dammed. The main difference being, back then when something went to print that was the end of the deign process. The web has made designers greedy and lazy. I honestly can not remember the last time I was handed a finished psd. Designer like to state as fact that they can't be expected to finish a design without first seeing a half baked idea of something built for their amusement first. To this I say: if Einstein can postulate the theory of relativity by imagining himself atop a photon travelling away from a star at the speed of light, then it's not unreasonable for a designer to imagine what the site will "feel like" with parallax scrolling.
I love design, and rather than whinge and moan about how everyone else didn't care, I learnt code. Articles like the one linked to here reak of self entitlement and laziness.
The solution, of course, is to pair with the designers, and say they can't leave until the edits are done for all supported interfaces.
Every time. Every page.
Their designs will become more practical quickly, or the library needed to support their vision will organically grow. But they need to be in the room with real consequences for their PSDs.
>>> My previous job (web shop) hired supposedly "rockstar" designers on several occasions.
In my experience, you can have designers who know the web and you can have graphic designers who don't have a clue about the web, yet decide they want to be "web" designers.
The latter seem to pop up more frequently these days and I would agree it is frustrating, time consuming and incredibly worthless. Worst yet, are graphic design firms trying to get into the web and use your company as their guinea pig. Again, completely worthless.
As such, I've taken quite a bit of time to learn design myself so I have at least some authority to call bullshit on stuff they try to pull and head them off at the pass. It this point, it's been my only defense and has been somewhat successful in not allowing these types to poison the well so to speak.
I would generally agree, any good designer I have worked with have been able to code for the most part html, css. Even if it is just dreamweaver or what ever. And being able to do those and have a general idea of how things work on the web allows him/her to produce significantly better designs then someone who has been doing print his entire life.
Where architecture is concerned this is normally true, but the exceptions are interesting/illustrative. When Frank Gehry was designing the Guggenheim Bilbao, he took stiff cloth and folded it into the final shape. Actually, y'know, making the building was someone else's problem.
Why do you assume all designers are even working on HTML/CSS apps? When you get down to mobile, do you expect them to be able to code in C++/ObjectiveC/Java?
A good designer will understand the limitations of the platform they are designing for. My wife designs for S40 feature phones with plenty of limitations. There is plenty of back and forth between development and design to ensure that the design works with the limitations of the software and hardware (though devs often push back too soon).
> This is 2014 and I don't think there's a place for single-skill design queens any longer.
I know what you're saying. But it reminds me that I would have loved to make a website with Jan Tschichold, Paul Rand, or so many other graphic designers who never even knew the web. (I'm sure they would also be interested in learning the details of the medium, even if they didn't want to code for it.)
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.
> moving a button 3px to the left shouldn't be a problem for any self-respecting developer
That's exactly the kind of thinking that developers abhore. Imagine that the whole interface is built on top of a planned framework that follows strict rules and conventions. This button is following the exact spacing and dimensions implemented in the framework, nevertheless the designer's static mockup is different for some reason (i.e. designed in photoshop).
Now, moving this specific button 3px to the left could be as easy as a `margin-left: -3px` or some other simple line of code, but that is a hack/code smell that will be met with contempt from everyone who looks at it in the future, a maintenance burden, and is deviating from the established standards created in collaboration with the designers themselves...
Other possible scenarios are interpolation mismatches, rendering differences between browsers, padding/borders unaccounted for in the original design, dynamic content that by chance nearly aligns to other element, etc etc. Very rarely is the case that the developer simply wrote 6px instead of 3px by mistake.
This happens way, way too often, and the resistance offered by developers is completely understandable.
> Now, moving this specific button 3px to the left could be as easy as a `margin-left: -3px` or some other simple line of code, but that is a hack/code smell that will be met with contempt from everyone who looks at it in the future
Yep, that's a compromise. But if it makes the product better overall, it must be done. If the designer says so, I believe them -- and if I say that a designer's request would lead to a significant setback for our production schedule, they believe me. It's not the matter of designer/developer interaction, it's the matter of product value.
I too abhor such things, but when a designer asks for it, I do "position: relative; left: 3px;". This is exactly what relative positioning was made for, and it makes the developer's intent obvious.
There's no point in arguing about this without context, since it's really all about the context. That is to say - depending on the framework/code base/whatever you're working in, just "do[ing] position: relative; left: 3px;" for a specific page element could actually be quite a chore. Not just now, but for the next guy as well.
position:relative creates a new stacking context that could interfere with other styles.
Anyway, one-off hacks like that every full moon are not an issue to most developers, but you'll usually see they come in a constant trickle; after experiencing that for a couple years a strong emotional response naturally develops :)
Furthermore, moving the button 3 px to the left might take a ridiculous number of man hours, and it's demoralizing work. Most coders are making smart trade offs and balancing a number of things to maximize productivity. How much is that 3 pixels really worth? Why don't you try again, and think of a way to design the interface that doesn't require that 3px move?
It's the developer's responisbility to estimate how much work a particular task requires. If it's too much work for too little benefit, no sane manager/designer would insist on that 3px move.
I can't speak to the parent's tone, but having worked with excellent designers who can and cannot code, I have often found that those who have made the choice to learn to code, even just a little, produce a better outcome.
You see the same thing on the flip side of the coin with frontend engineers who make the effort to learn about typography, color, emotion, etc. Broader skillsets produce better software.
Related - moving a button 3px to the left shouldn't be a problem for any self-respecting designer, either.
If you mean beautiful mockups than will win a contract with a client and that's all, perhaps your 100% photoshop person will be the best suited.
If you mean building an interface acknowledging harmony of the UX, the user and clients needs, the medium, the strengths and weaknesses of the platform it will be built onto, the project budget and the maintenance afterwards, a 50% person will be thousand times more valuable.
> moving a button 3px to the left
I think it's a stereotype of the request the lay man doesn't get but can cause a project to lose hours or days of dev if the request just goes through. If 3px from where your button is is another component, just imagine that component also being bind to specific size and placement rules (or like, it's actually not your component but some other library's one), and moving that button 3px might mean rebuilding the whole screen.
If it's such a big deal, just say no. I think the article would, too, argue "why you shouldn't move that button 3px to the left if it makes you rebuild the whole screen".
Totally agree. And I think the person saying no also has to explain the scope of the change. If it's actually waranted to rebuilt the whole screen for 3px at least everyone will understand the pros and cons and respect the amount of work that will be done.
100% designers only happen at the very bottom or with design teams. A hands-on design dev knows what's simple vs complicated and can design for it. They will easily outmatch a single designer.
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'.
The problem is that engineers are not very good at UI design. Both from UX and aesthetic standpoints designers are capable of making a better product. A good designer will give a consistently better result than a good engineer in terms of usability, UX, aesthetics and modularity.
Cats aren't very good at catching sticks an dogs aren't very good at catching mice. Therefore you can't have the dogs trying to do what a cat can do....
Except design is different. As a developer, once you have worked with some PSD efforts a few times and then worked with real dynamic content then worked with a real client to get the thing to actually convert sales, then worked with the client stats you have got a good grasp of when something is right on the design front. Plus you can open the css and do something about it. Or you can open up some stuff on the server side or put in some hack with javascript to get the usability to what it should be.
Designers are completely out of the loop after go live, they have done their 'lorem ipsum' stuff. Proficiency at UX comes from delivering the deliverables, testing, testing and testing. Listening to the client and the customers. It does not come from a few static designs.
I have never heard of a designer wanting access to the css to make that 3px change. They are welcome to it. They would make my day if they wanted to do that stuff. They do design for the web and the css is really over to them if they want to do it. The problem is that they would have to learn what a border is, what a margin is and what padding is. It is not difficult stuff.
The whole point of CSS is that the presentation is a separate thing to the content. Any developer would be happy to churn out the content blocks and sensible markup and hand it over to one of these PSD experts for them to get exactly to their 3px requirements. But in the real world it does not happen. Developers can dive in and fix something at silly o clock on a Sunday, but would anyone ever call a designer at such times even if it was a UX issue that was the problem?
Obviously there are some fantastic designers out there - allegedly - but, in general, designers don't do the hard stuff or even bother to work with live content. Far too many of them produce static nonsense in PSD format - a trade that should have been pronounced dead the nanosecond the iphone came out. They also perpetuate this myth that all developers are totally retarded when it comes to anything to do with aesthetics. Yet it is the developers that implement design, learning along the way. Rarely if ever is it the other way around, and, should a designer dare to do that they will get clumped in as a 'front end developer' and have some retarded PSDs foisted on them by some manager that thinks only designers can have any input whatsoever regarding UX/UI design.
How often do you think a developer tests something? A given page can be tested 100's of times. Along the way 'this checkbox might not be needed' or 'this dialogue box makes no sense' or 'this process is tedious' gets discovered. The guys with their PSDs just do not have that insight.
> As a developer, once you have worked with some PSD efforts a few times and then worked with real dynamic content then worked with a real client to get the thing to actually convert sales, then worked with the client stats you have got a good grasp of when something is right on the design front.
Most designers do not use photoshop these days; its all Illustrator vector format for anything but touch up. There are still some pixel junkies left, but these are mostly programmers pretending to be poor designers.
> Designers are completely out of the loop after go live, they have done their 'lorem ipsum' stuff.
Only in a failing company that doesn't have real designers or doesn't know how to manage designers.
> Proficiency at UX comes from delivering the deliverables, testing, testing and testing. Listening to the client and the customers. It does not come from a few static designs.
So you are saying designers are bad at UX because they don't conform to your narrow minded idea of what designers are?
From my point of view, you haven't worked with good designers at all. All the good designers I know work hard on their research (both theoretical and concrete, regarding their current projects) and user testing afterwards. In many companies designers are required to work with analysts to improve ROI of their products.
Although I completely agree that PSD is a terrible format for web design. I myself have been using Indesign and try to insist on designers using it when I develop.
'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.'
Ignoring the really really harsh and overly rude tone.
I wonder what the difference would be if this was posted on a designer version of hackernews.
The problem with your comment is you assume everyone can dabble in everything. When you work at a big co you are hired generally to do one thing, and that's it. Designers don't touch code. Developers don't touch designs. So while Sue may be able to do CSS, JS, Cocoa but isn't allowed anymore then Bob isn't allow to open up photoshop and start "playing color the fucking button on dibbble all day long".
"The problem with your comment is you assume everyone can dabble in everything."
How is it unreasonable to assume that a designer should dabble in web development? That's hardly 'everything' and it's highly relevant to their work and goals. Frankly it's remarkable to me that web designers can still get jobs without taking the time to acquire an in-depth knowledge of the engineering stack they're designing for, even if they don't work with it on a day-to-day basis.
Designers often don't even have time to touch code, even if they could. When your organization has more trouble hiring designers than devs, you need your designers doing design 120% of the time.
Definitely, ideally you should manage your business so that all your specialists are busy doing their specialties. Designer salaries should rise if they are harder to find than devs are.
Yes, that article felt somewhat arrogant. Designers should shut up about the obsession with details etc. already, it's getting annoying. We get it, ok?
I sometimes design too and must say, programming is harder -- it's more intellectually demanding, less rewarding and on average more frustrating. That's why I value programmers' work more.
I'm a programmer and a shitty designer. While I can get 'minified'/simplified designs, I could never (at least not without a lot more practice) get to the point where I'm creating beautiful works of art out of my UI. Sometimes I see designs that are just so fantastic - this has happened so many times in history that those designs become fads to standards and then 'old' (see Flat UI). I think a designer's job is equally hard, and when there is no innovation or problem solving (you're not creating something unique - following the fad?) then it's along the same lines of using pre-existing software and making only small changes to it to make it useable for you (Wordpress plugins and themes).
TL;DR: Good designers who create new or unique works are different from designers who follow the trends and make similar/copy-cat designs. Just as a programmer who uses pre-existing software is different from someone who is building one from scratch.
I have worked with numerous programmers who try to avoid front end design because they just can't wrap their head around it. They can write great code that is easy to read and works great, but when they have to make an elegant or pretty design, they struggle.
Both designs and programmers work should be valued when it's good.
I've worked with Braden (the author) and he can indeed code - he built a mean prototype for some user testing we were doing. You can see in the second half of the article that he also makes the argument for pragmatism and working what is provided by the platform.
Obviously you have strong designers and weak designers. The strong designers are focused on the user experience and providing a consistent interface that has a high degree of fit and finish.
Users have a low tolerance for mistakes and seeing a couple things off by a pixel or two can make a product look immature and can take way from all the hard work that was spent building it.
I disagree with this. I'm a web engineer and I work with designers. I dont have the ability to design pixel perfect interfaces and I respect that skill in someone who can. I also dont have the time to spend countless hours interacting with a product manager who trying to figure out a finished design.
* 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.
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.
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.
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.