No, designers aren't crazy. You just don't understand a very fundamental concept of design. It even applies to engineering. It's okay—many people have the same frustrations as you do.
But those who care about the details achieve truly high quality results overall. It extends to all areas of the design, not just to the parts you can't see.
In the movie "Who Framed Roger Rabbit," there's a scene in a dark room where Roger Rabbit (an animated character) flies across the room, knocks a hanging lamp around, and the lighting becomes so dynamic that all the shadows move around including the animated character's shadow. Here's the scene in question: http://www.youtube.com/watch?v=_EUPwsD64GI
This was such a small detail that it would have been forgivable if the animators had left it out entirely: if they had not moved the lamp, kept the shadow steady, no one would have really noticed the difference. It would have been 100 times easier to animate and the effect wouldn't really have been that different.
But they did it anyway. The term was later coined, and "bump the lamp" is used throughout Disney (and probably other organizations) to mean something akin to "go the extra mile"—but I see it as having a special significance to design.
You're right, most people won't notice. By that logic, you could cut corners a lot of other places too. You could be lax about button colors matching exactly, or per-pixel sharpness on the map and buttons. No one would probably notice.
But if you go for every detail like it was the most important detail, you have the possibility of reaching a level of design quality that is superlative, and some people will notice. Others will not notice directly, but will see that the piece exudes style and quality subconsciously, due to the attention to small details. If you carry this into other areas of your work—programming, customer service, market strategy, marketing, and more—then you have a chance to create something of true quality.
If you don't pay attention to detail at that level, well, you might have the chance to actually get something done. Yes, it's a balance, like everything else. But you have to know that it won't be quite as good, and understand that yes, you are sacrificing something, even if you can't see it.
In my experience, the assumption that "most people won't notice" is usually incorrect.
The fact of the matter is that people usually do notice, if only subconsciously. If you show someone a clip from a Disney movie and a clip from a Hanna-Barbera cartoon, they will be able to tell that the animation quality is much crappier in the latter. They won't be able to tell you why, but on a visceral level they will be able to feel the difference. [1]
This visceral feeling of "quality" is what gives Apple's brand such cachet. Sure, their skeumorphism can be tacky, but it's never slapdash. Their apps always run at the highest framerates, and their touch interactions and animations have always been tweaked to a level that their competitors can't match.
Now, if you asked someone what the difference was between Mobile Safari on an iPad Mini and Chrome on a Nexus 7, no one would say "the scrolling is much smoother on the iPad, and the variance in framerate is much lower as well, which contributes to a feeling of responsiveness and playfulness", but those features still contribute dramatically to the "feeling" you get when using one of the two devices.
Now, sometimes it really doesn't matter. The example in the OP seems particularly silly. However, don't underestimate the value of "bumping the lamp" when it comes to design or interaction development. People will notice.
[1] The answer to the "why" has many parts, but mostly involves the fact that Disney animation runs at 24fps while HB cartoons ran at 12fps or even 6fps. Disney animation involves characters that are carefully articulated and that move realistically and with a sense of weight behind them. Also, the general quality of animation and camera work was just better -- look, there are a lot of reasons. They all add up to the difference between Scooby Doo and The Little Mermaid.
But for all its lazy repeated backgrounds and bongo-drum running Scooby Doo has lasting cultural relevance and The Little Mermaid is all but forgotten, despite being decades newer?
It sounds like they optimized for the wrong thing.
If we're going to be pedantic here, lets at least attribute the continued success of Disney's vintage films to their appropriate source: Disney's relentless marketing.
I'd argue that Disney's animated works as a whole is much more culturally relevant than Hanna-Barbera's portfolio. But I do agree that quality of animation is not the deciding factor in that determination.
Forgive me, the argument that people notice but only subconsciously strides dangerously close to arguments for things like God, at least insofar as being a hypothesis which in principle cannot be tested.
You can take your Hannah Barbara example as proof that some intangible things have an aesthetic impact, but you still can say when you see the two cartoons that one seems to be of better quality -- I hardly thing that is 'subconscious'. I think this article is intended to focus on the things designers do that are stylish yet unremarkable or wholly unnoticed, which any sensible designer must agree is something of a problem for web designers.
Hana Barbara has an iconic style. It's kind of offensive to use that as an example of "crappy" animation. That's like saying Jackson Pollock's "crappy," slapdash paintings could never compare to the intricate detail of the Mona Lisa.
HB does have a very iconic style, but that style was deliberately chosen to make it easier to get away with low-quality animation techniques [1][2]. The HB shop needed to run on a shoe-string budget, and they had to cut corners wherever they could.
Now, it works because of the HB cartoons' light-hearted style and premises, but would seem tacky and ridiculous for a film or episode attempting something grander (i.e. a feature film like The Little Mermaid or Toy Story).
[1] For example, many HB characters don't have necks, or have extremely thick necklaces or collars where a neck would normally be. This allows you to swap out head and face animations with much greater freedom, and makes it harder to detect camera errors when the head and the body don't quite line up correctly. Is that bad? Not necessarily, but if you rely on too many of these tricks you end up painting yourself into a corner.
[2] Also, some HB characters don't even walk correctly. Their torsos and upper bodies stay perfectly motionless while their legs flail about beneath them. It looks cute and storybook-like in certain applications, but completely ridiculous in most others.
I see where you're coming from, but to me all you're writing is an excuse for unlimited perfectionism. Perfectionism rocks of you're among the lucky few who're in a situation where you can get away with it. In most circumstances, however, there's a product to ship, with the end of the money in sight.
I mean, in terms of the 80/20 rule (the last 20% of quality costs 80% of the time), we're not talking about turning an 80% thing (i.e. typical in-house enterprise software) into a 90% thing here. Hell, even going for 95% is something I believe we should all go for, and fight our colleagues, bosses and project managers, and customers for. But the OP's example is more like turning 99.5% into 99.8%.
Probably very true, hence my final sentence on balance (admittedly a feeble nod to rationality, but still).
Personally, I believe that much of the value created lies in the final 20% that takes 80% of the time. If what you say is true, near anyone can create something that's 80% of the way there. It's your job to get as close to 100% as you can realistically, while balancing time and money and value. It's not an argument for unlimited perfectionism; it's an argument for quality. The higher you can get, the better you will produce, and the more you will succeed. And don't just limit this to product quality; extend it to everything you do (including customer service, including planning and resource management, including hiring and culture) and you'll create a company that has a chance of being better than the others.
Perfect? No. But if you're not striving for creating something of quality (in other words, of value) then what are you doing, exactly?
Edit: There's a caveat here, I think. It may not be your job to worry about every design detail down to the pixel. It doesn't have to be. You can find someone who can help you produce what you need at the level of quality you desire (like the designer the OP is talking about, presumably) and you can worry about all the little details of running your company. Details that I'm guessing a designer might not understand or care about, but you do.
Why do you believe the value created lies in the final 20%? Very few (though some exceptions are notable) derive their earnings from the value at the 'long tail'
I feel the same way. When you have a designer who strives for perfection, they seem to think of the edge cases. And when they push you for pixel perfection, it only makes you that much better. Makes me remember how it is not to be "the best" or the one who cares the most in the office
Quantifying gains is beside the point. I don't think anyone became a great designer or a great programmer by only ever striving for "good enough". Yes, at the end of the day you are worthless if you don't ship, but you are half-worthless if everything you do is a hack.
Maybe for this case in isolation going the extra mile to this level of perfection is not justifiable, but if the designer is doing good work and meeting deadlines then you should keep your bean-counting micro-managers far far away. To attempt to quantify everything (even in programming) is to take the human element out of creation, and that runs a severe risk of throwing the baby out with the bathwater.
Keep in mind that your angle on this is the design equivalent of "who cares about [source control/code reviews/proper architecture], it works right?"
There are coders out there who strive for absolute, unlimited technical perfection. They rarely if ever ship - and ditto for designers in that boat.
In reality most designers, and programmers, walk a balance between the bottom-line functionality of their work and less concrete (and more subjective) qualifiers like code quality or sub-pixel scaling.
There are many analogues between design and code here. Most people here would agree that sloppy coding standards aren't deadly, but encourage sloppiness on a larger scale over time. Ditto, sloppy design is insignificant in the individual case, but have the tendency to accumulate and lower the bar.
The example OP chose was particularly bad, mostly because as an iOS dev I know for a fact that getting 1x assets right doesn't take that much time. The usability improvement over time invested is not atrocious - certainly nobody spent an extra week just to get some pixels to line up just right.
The major problem with scaling 2x assets down to 1x devices is that thin features become muddy and blurry, while code-wise UI elements may become aligned against half-pixels, resulting in filtering that produces blurriness. Both the design and code elements of this are easy fixes for any competent iOS developer/designer duo, and takes no more than an hour or two at the extreme most. You get a pretty clear legibility improvement for not a lot of man hours.
Not to mention the very noticeable blurriness of the buttons in the "unfixed" versions - things that users do notice. So much so that some of them can actually articulate it (as opposed to merely being a subconscious annoyance).
One of the best ways to balance this is deadlines + a perfectionist mentality. Be obsessively perfectionist while working but commit yourself to shipping. That'll ensure that you also get outside feedback, which in turn will help you produce higher quality work in the long run.
Thats the point. Design is all about unlimited perfectionism according to some imagined idea... and its also the reason that most artists and designers are broke. The pursuit has little to do with the rationality of time management and efficiency, rather, design is about pursuing an idea of perfection that cannot be achieved.
You are confusing art with design (formerly known, perhaps more accurately, as commercial art).
If you are creating "unlimited idealistic perfection" you are creating art. If you are selling soap it's design.
While soap may not bring about intense discussions about its design, and one might say that it is less designed than the UI of the app the article talked about, the ideals that art and design revolve around are wholly intertwined. Art and design talk about things that would seem ridiculous and esoteric from an engineering standpoint (thus the primary argument of the article that none of the changes made any difference to the usefulness of the app). These are things that hold little value outside of the face that they communicate the purpose and intent of the app or button better than a different size or proportion. There is a reason that design schools have such a close relationship with the art community, while designers don't always maker art, and a bar of soap may not seem to be art at all, disconnected from its purpose, the design of a simple bar of soap can be put in a gallery and be viewed as art. (see the toilet that started the Dada art movement).
Design is not art in and of itself, but you can't talk about one, without talking about the other.
I'd say that Nokia is in a predicament partly because their software sucked for a long time, not because they "weren't perfectionist" - their hardware has been very good for a long time, better than most Android manufacturers' and not so far behind Apple.
Nokia has thought for a long time that they were a software company. They have been repeating this back in 2005 or 6 (when I was there). I had a colleague who kept saying that this wasn't the case. Me, I don't know. I think it's a different issue. To me, it's about big corp middle and upper management: nobody dares to do big changes. They had a linux based OS back in 2004 or something. But went on with Symbian and NOS, because nobody dared to declare that they should drop Symbian and focus on Linux. So they released a single phone (after 3 series of mini tablets) with their linux based os.
And tried polishing symbian. Which had a number of terrible design decisions at the core (which may or may not have been good ones 15 years ago, when they were introduced into EPOC, the ancestor of Symbian). And those decisions affected everyone who worked with it, both internal Nokia developers and external app developers. It made developing for Symbian a pain. It was natural, that iOS and android (and Windows) passed by.
I read this article and immediately jumped into the comments, praying that there would be a comment like this - thank you. Very well put -- details are what separate an amateur from a master.
To add what little I can to this, the reason that drives me to go to these lengths is the craft. Design, like code, is a craft. A good craftsman just does not leave mistakes in their work purposely. Whenever I do this it slowly drives me crazy until I either go back and fix it, or drop the project entirely (if there are a lot of mistakes and/or things I don't really like), usually citing some reason like 'it's too messy' or 'i lost interest'.
For me, design and programming are not all about a/b testing, 100% time efficiency, etc. A lot of it is about art -- making something you know is great and shipping it. When you know something is wrong with your work as an artist, it will bother you until it's fixed.
I don't understand where people are getting the idea that we are to ignore balance, constraints, and reality in deciding how to complete a project.
Absolutely not the case. We're talking about quality specifically, and why someone might choose to pay attention to finer details versus ignoring them.
Your reasons for ignoring details might be perfectly valid and entirely appropriate. The project may not call for artistry and mastery. All very good points for a different discussion.
Don't think for a moment that those who believe high quality is an important factor are implying that it is absolutely necessary. That is simply a false dilemma.
My answer to the parent comment is more or less exactly this. If you're just trying to ship a mediocre quality product, that's fine. I know there's a place for that and let's face it, sometimes it ends up happening at work because of contraints. But that is never, ever my goal.
I'd venture to say that it takes much more then just details to separate an amateur from a master. Knowledge of theory, an eye for errors big and small, etc. Maybe the details separate the good from the best?
My point was that the ONLY thing that was listed was details being the separating point, and that there is more to it then that. It wasn't meant as a quip just a clarification, if anything a question even, not requiring a snarky answer but maybe a genuine one. But, I forget, I'm on the internet and snarky is everyone's default for whatever reason.
As a coder & semi-pro-designer I reached the conclusion that little bad/ugly things add up (or even multiply!), eventually resulting in something that looks bad/ugly even to average-joe on a greasy sunlit screen. If a badly scaled rounded rectangle is mixed with bad font scaling/rendering and on the next iteration a bad color-scheme decision, the ugliness of the whole is more than the ugliness of the parts added up. It sounds vague and artsy but that's how I find it: "harmless" little ugly things add up to an aesthetic carnage. Yes, it's "premature optimization" if you look at things like a programmer, but the "designer mind" can't really separate "optimization" from "just getting things to work".
> It sounds vague and artsy but that's how I find it: "harmless" little ugly things add up to an aesthetic carnage. Yes, it's "premature optimization" if you look at things like a programmer, but the "designer mind" can't really separate "optimization" from "just getting things to work".
The same sort of technical ugliness and lack of optimization happens in plenty of programs.
In theory, one should never optimise prematurely, and get the application working first. Only at the end profile the speed, find the one single slow loop or algorithm, and optimise that.
But plenty of applications acquire slowness not due to one core slow algorithm, but a lack of concern for even trivial optimisations everywhere. You end up with something like Eclipse where a keypress can take multiple seconds to appear, or a "cancel" button might take minutes to stop whatever task. And there is no place to optimise, because the inefficiencies are spread out by tiny bits everywhere.
A fundamental point IMO that you are missing is that there are a few differences between a work of art and a programs UI.
1. A work of art is created by definition to be beautiful. While a beautiful UI is awesome and definitely something to strive for, it is not the end goal.
2. A UI can be changed after its release. Unlike art, you can release a UI and then later change details that are important.
3. Most companies do not have the manpower or time to actually get to the place where the entire product is pixel-perfect. pg's mantra is: "release early." This means that not everything is going to be perfect and you have to decide what corners can be cut and which cannot. (You cannot simply state, I am going to cut NO corners).
4. A UI is likely to change. When you first release a UI you dont really know how it is going to be used. Therefore, as the OP suggests the improvement from 95%-98% really does seem like a pre-optimization.
That said, the UI should make the experience easier in that it aids the function. I would take it a little beyond that where you want something attractive to look at, but it doesnt necessarily need to be in the v1. As the UI matures over time beauty in design becomes a more important goal.
"A work of art is created by definition to be beautiful."
Why is the always treated as truth whenever non-artists discuss art? This is a backwards, 19th century era concept. Art broke out of this generalization over a hundred years ago.
Awesome comment. And thanks for the info on the Roger Rabbit bit, that's fancinating. I agree with you that pixel-perfection seems like a waste of time to a non-designer ("who the heck is going to notice?!?!" is the common refrain), but I think of it like this: no, people probably won't notice one, maybe two deviations from an ideal asthetic or consistancy. But those add up fast, and pretty soon you have an interface that's a mishmash of font sizes, colors, textures/no textures, etc., and people do notice. They notice because a competitor has gone the extra mile and paid attention to detail, and now they're crushing it and you're looking like a second-rate, half-baked wannabe. Design quality is every bit a competitive advantage in not only consumer software, but even enterprise software now.
When I inspect a cathedral, that is perfectly considered at every level of detail, I know more powerfully than at any other time that life is worth living.
It's easy to pick extreme examples to make it seems like designer obsess over unimportant details. But a designer that cares about the exact shade of blue or creating different versions of assets for each sizes will also care about making sure that your brand is used the right way or that your user interface makes sense.
Of course, with experience also comes the knowledge of which things are more important, and which can be sacrificed for the sake of saving time.
But it's often hard to tell the difference. A lot of details that seemed superfluous at first turn out to be crucial. So if you can afford to, it's safer to bring the maximum level of care to everything you do.
A plea to designers.... Read the original piece carefully and try to avoid being defensive. This is an important post for all of you. I've been a defender of Design and designers for 2 decades now. But you all are your own worst enemies. This post should serve as a chance for all of you to learn why you are often Balkanized in business decisions and business structures. It should serve as a chance for you all to show that you actually understand business realities and can propose rational arguments.
Instead, reading through these comments I see pretty much nothing but personal opinion, vigorous hand-waving, very poor and stretched-to-breaking analogies and the usual "because it means this to me" and "because I say so" and "because... Apple" arguments.
I'd suggest reading again with the mindset of "this is the way non designers think about us" and then come back and (with facts this time) explain your perspective.
And remember... this is Hacker News.
We work at Start-ups.
We believe in shipping early, shipping often, and iterating to improve.
Your answers and perspective MUST work within this construct or we will ignore you (and you will thus teach all of us that designers are, in fact, crazy).
Oh... and as a hint, if your response includes ".. you don't understand .. " at any point... please understand that you are insulting the person you speak to.
> This post should serve as a chance for all of you to learn why you are often Balkanized in business decisions and business structures. It should serve as a chance for you all to show that you actually understand business realities and can propose rational arguments.
Heh. Because "business decisions" are always so rational, demonstrating a genuine understanding of the product and what the people that actually are going to use it will want from it?
> And remember... this is Hacker News. We work at Start-ups. We believe in shipping early, shipping often, and iterating to improve. Your answers and perspective MUST work within this construct or we will ignore you (and you will thus teach all of us that designers are, in fact, crazy).
Sigh. Some of us want to ship genuinely high-quality products, not ship whatever we manage to shit out every other day.
If my users are noticing my bugs (or design faults), that adds up to an aggregate middling opinion of my product. One thing you got right -- I do want to be Apple, not Time Warner Cable.
> Ball's in your court.
Not really. You sound like someone that will willingly produce mediocre products, and I don't really know why anyone interested in excellence (and the rewards that it brings) would want to work with you. So this becomes a self-fulfilling prophesy for yourself.
You sound like someone who ships a mediocre product because you run out of time trying to perfect everything and end up having to leave stuff unfinished because of deadlines.
Most products have a budget and deadlines. Your job as a designer is to do the best job you can given the time and money allotted. There are very few projects that have unlimited time and unlimited money.
I've been on too many projects where designers didn't get that and given the promises to distributors, retailers and advertisers we had to ship a worse product than we wanted to because the designers spent to much time perfecting certain elements and not giving enough time to others.
I've worked with quite a few designers. (Mostly I have hired them for my projects.)
And many of them just lack pragmatism. There's a point where stuff is $good_enough and a user wouldn't ever notice that it's not optimal - but still many designer tend not to accept this. They strive for perfection. (Which might be fine if they weren't burning my money.)
But that's not confined to designers. Lack of pragmatism is generally a problem. Many engineers I know won't let a problem go until their solution would work for every possible edge case - even if it's impossible for said edge case to happen with the current project.
Totally agree; been guilty of it myself in the past. Getting the perfect modular golden-ratio-derived grid is less important than shipping, but being excellent is better than being good.
Designer culture in startups is still relatively new; most of us are still relatively recent imports from graphic design & advertising agencies where things are totally different.
But I've seen programmers exhibit the same deadly perfectionism in startups (namely, premature optimization. overly-ambitious architecture for week-long MVPs, and writing hundreds of lines of Rspec tests for code that is designed to be thrown out after an experiment).
> But I've seen programmers exhibit the same deadly perfectionism in startups
Yeah, programmers are not immune to that. When I was younger I wanted to be a game developer. So I made games ... well, I rather designed game engines, threw them away as I came up with 'better' designs and threw those away too because I dreamt up an even better system.
In the end I didn't ship even one game in my 6 years of being an aspiring game programmer :)
"Ok... Now I see some differences. On one, the
buttons are slightly larger, the colours slightly
more nuanced, the shading is subtly different. If
I zoom to an extreme level, the font on "ebay"
in slightly smoother."
I understand the above is frustrating, however, you are missing the main reason the image needed some extra love.
The main difference is pixel fitting [1]. The fuzzy border lines on the buttons are like "nails on a chalkboard" to me. "Nails on a chalk board" don't actually bother me that much but I notice it. For many cases I would just ignore it. However, if I am shipping a product that I am hoping will get free advertising from people talking about how beautifully it is designed, I am going to pixel fit the damn thing.
In this case, the designer is not being crazy, he is looking out for the the bottom line. Free word of mouth advertising and free blog articles written about the beauty of the pixels contribute to the bottom line much more than the cost of doing a little pixel fitting.
> Free word of mouth advertising and free blog articles written about the beauty of the
> pixels contribute to the bottom line much more than the cost of doing a little
> pixel fitting.
Really?
Give me the data to back up your bottom line claim. Because in my (5 and counting) start-ups I've seen little to no impact on the bottom line from design blog posts.
Sorry, I didn't mean design blogs. I am talking about normal blogs and tech blogs.
I believe products that are designed well and polished get more attention from blogs and receive more word of mouth recommendations. I believe one of reasons iOS and the iPhone helped propel Apple into becoming the largest company in the world was Apple's attention to design details. However, I have no way to test or prove this theory. So please disagree if you like.
1 - the link between blogs of all sorts and the bottom-line is tenuous at best. If you're an ad revenue business, you can make the argument that all traffic has an impact on the bottom line, but suffice it to say that none of the advertising supported start-ups I have been involved in have seen sustained valuable traffic referred in from a blog.
2 - Normal blogs and tech blogs don't write articles that go into detail on the minutae of the design elements in a product's UI. That's limited to design blogs.
3 - Personally, I'm getting kind of tired of the default defense of most designers to this sort of criticism ("because Apple"). Saying that Apple is where it is because of Design not only ignores the market, product and business realities that have lead to Apple's (recent) success - it also ignores the many ways in which Apple's design is sub-standard or even bad (resulting in people copying bad design patterns "because Apple did it").
Design absolutely matters when a consumer is interfacing with your application, and pixel-pushing is actually quite important. It can be used as a talking point - the SeatGeek application is extremely well-designed for it's vertical, and is meant to be pleasing to use (thereby hopefully driving more eyeballs/higher conversion).
Internally, I think it's also a way to have the designers/developers proud of something they helped accomplish. No, I didn't perform any of the design on the SeatGeek app, but you'll bet your ass I'm not complaining about the three hours I spent uploading about 100 - outsourced and therefore not named well enough for me to automate it - logos to S3 for use in the app. It's a source of pride, and it's what staves off the burnout.
Reference: I work on Operations at SeatGeek, and after slicing up a PSD to very exacting specifications two years ago, I know exactly what kind of a difference design can make re: tech blogs/traffic.
Font hinting is precisely that, and it works quite well, at least for body text. I'm sure that more critical applications like logo design still require some hands-on work to get the best results.
As with any vector rasterization, you do trade accuracy for pixel fitting, but for things like small body text you almost always want that. For example, if the 1 pixel wide vertical stem of a "b" is supposed to be between two columns of pixels, the hinting algorithm can push the stem either left or right so it is rendered as a single black column of pixels, rather than two gray columns of pixels. This will look less fuzzy, but it will technically cause the "b" to be closer than it should be to an adjacent character.
Yes, after I wrote that it hit me: font hinting would qualify as automatic pixel fitting.
I was thinking about something more elaborate, like an algorithm that takes distances between neighboring elements, proportions and other factors into account (and which can be tuned to include/exclude factors).
An example "smart" rule would be: If a group of elements are aligned, the same size and the same distance, they must remain aligned, the same size and the same distance after the processing
Ideally it would be a plugin for a vector graphics application which could then allow the designer to add finishing touches to the places where the algorithm got it wrong.
There's automatic hinting for type rendering, so I guess those algorithms could be generalized.
But you can probably go far by just fitting everything in your 2x version to even pixels and using even-width lines; then the scaled-down 1x version will be sharp.
Just as crazy as programmers are for caring about their indentation or doing things "right". There are times when you need to rush a little and you can't do things perfectly, but it feels good to finish something and know you did it "properly" - whatever that may mean to you.
If you have seen Jony Ive's tribute to Steve Jobs, you may recall the part where he talks about "giving a damn". I think that is very relevant here.
Writing "good code" is always preferable, especially when you do things "right" the first time.
But what happens when you want to refactor something when 1) it's not strictly necessary in terms of functionality and 2) it will cost the client some non-zero amount of money. You easily slip into a gray area that this visual example illustrates well. Sure there are differences but are they material to the overall design goals? It's hard to say yes.
There's no such thing as "giving a damn" in an absolute sense. It's hard to say that any software product is ever done. If that's the case then it's the programmer's / artist's responsibility to say when something is good enough for the project's current goals.
If you had unlimited time and money, what would you do?
The higher quality thing is still higher quality, regardless of time or value constraints. If you choose a lower quality path while acknowledging you're balancing time and money, you're still choosing lower quality.
Realistically you can't achieve perfection (sometimes even completion) because you don't have unlimited time or money, and there are always new variables. But it is important to strive for that high quality as an ideal, even if you can never reach it. You know it is still better in some absolute sense. It's always out there as an intangible goal, and if you reach for it, you can understand and center on that balance beam even better.
>> The higher quality thing is still higher quality, regardless of time or value constraints. If you choose a lower quality path while acknowledging you're balancing time and money, you're still choosing lower quality.
Framed like that I would say "yes, I never want to deliver something of 'lower quality'", but in this case (the two interfaces) one really doesn't qualify as lower quality. We're talking about the difference between "good" and "slightly, almost imperceptibly better". Having said that I'm not a designer and maybe if I were I would have a different opinion about this particular case.
>> But it is important to strive for that high quality as an ideal, even if you can never reach it.
No, I think it's entirely possible to deliver high quality. But we do have to deal with the law of diminishing returns and it's up to us (programmers, designers) to know what's best for our client (or ourselves).
Perfection is unobtainable by it's very nature. If you froze the world and left the designer alone for centuries what came out would not be perfection. Don't kid yourself that it would be otherwise.
I never said it was even real. All I'm saying is that some things are higher quality than others, and the higher quality things are better. It's a simple tautology.
I did say, "realistically you can't achieve perfection" which would appear to indicate that I'm not kidding myself here.
Understanding quality in both the realistic obtainable realm, as well as the unobtainable more-pefect level allows you to differentiate the two, and make conscious decisions about the level of quality you're targeting as well as your ability to do so in reality. The higher unobtainable level of quality doesn't even have to be close to the perfect you're talking about—if you have time and money constraints, that unobtainable level of quality might be a lot lower than perfect.
If you dismiss all levels of quality above a certain level as being this mythical unobtainable thing before even attempting to think about them in the abstract, then you've cut yourself off from a true understanding of the balance and compromise involved.
Of course you can't achieve it, but that doesn't mean you shouldn't be aware of it.
At some point this idea becomes a philosophical discussion and ceases to be useful. Just as at some point, your perfectionism becomes a philosophical endeavor and ceases to be useful. There is a balance where the pursuit is useful and complete.
But this leads to stasis if you are given unlimited time and money. That is, if you did have your ideal constraints, would anything ever be produced?
I read some short story (that I wish I remembered the title of) when I was a kid about the idea that achieving immortality on earth had caused people to stop producing anything useful in their quest for perfection.
I'm going to copy verbatim a comment I posted elsewhere in this thread. Apologies...
I don't understand where people are getting the idea that we are to ignore balance, constraints, and reality in deciding how to complete a project.
Absolutely not the case. We're talking about quality specifically, and why someone might choose to pay attention to finer details versus ignoring them.
Your reasons for ignoring details might be perfectly valid and entirely appropriate. The project may not call for artistry and mastery. All very good points for a different discussion.
Don't think for a moment that those who believe high quality is an important factor are implying that it is absolutely necessary. That is simply a false dilemma.
The differences presented in this article, however, clearly fall into the category of "worth it" because of how minor they are. I think it's easy to imagine code analogues - such as coming up with good variable, class or function names.
Properly indented code is like properly layered design graphics. It should be a habit such that you're unconsciously doing it all the time, regardless of whether you're otherwise doing things "right" or taking shortcuts to be "good enough for now".
Of course. There are differing levels of perfection, however. For example, something I despise is when, somehow, spaces are left at the end of a line by hasty colleagues, e.g:
"someFunction(); "
Their existence doesn't damage maintainability, performance or code readability - yet to me it feels wrong and I can't stand it.
Of course it damages maintainability when moving the cursor around becomes erratic. Your colleagues should probably configure their editors properly to remove trailing whitespace.
the big difference here is that for a programmer, doing it "right" means making it better for them, not for the end user. it's mostly about things like being able to measure how "correct" the software is, or how easy it is to change things in the future. indirectly, this can make things better for the end user, but only inasmuch as it makes it easier for the programmer to make things better for the end user.
the things the OP talks about are things that designers claim make a direct difference to the end user. if you know a programmer who claims that about indentation, he is, in fact, crazy.
When I design, I am placing myself in the viewer/users shoes and thinking about what it is they are trying to do/understand. The subtile differences may not be critical when viewed at first glance but the designer thought it affected the experience enough when they were thinking about it from the end-user/viewer's perspective, that he/she thought it needed to be slightly different.
Sometimes it is just insanity. Yes, I admit it is a bit crazy to spend 30 minutes on something that no one will really look at twice and I'm completely guilty of it. And as a designer, sometimes we can't help ourselves... because "it just doesn't look right." I can't explain what "right" is but I'll know it when I see it... so I'll experiment with a numer of different approaches.
Sometimes however, it's a genuine care for the experience and the cumulative effect of sweating the small things showcase a level of polish and care that Apple is/was famous for. You just have to decide whether it matters to you (as a company) or not.
Some of the design choices made for the two versions seem like just an evolution in the style for the app that weren't back-ported to the older version. For example, the different colors of orange for the button, gradient shading, etc. Other changes are adjustments that, from his eyes, seemed necessary to make the experience better/acceptable on the 2x version, such as the sizing of the Search button, border bevel, etc.
Having literally bruised my fingers trying to appease a visual designer who wanted browser rendering to look exactly like Photoshop (for instance, the CSS-drawn gradients didn't meet her approval, so we had to lard the interface with background graphics), I'm now in the "Put designers in straitjackets until they learn the fundamentals of modern Web application design" camp.
It's the year 2013, and your competition is using frameworks like Bootstrap or Foundation to release something while your dev team is fussing over bespoke line-heights specified in points. Maybe your app looks better, but how many users are waiting for that placed-just-so button image to download?
We take design very seriously, and thats because better designs have been quantifiably proven to have a meaningful impact on our bottom line. That means sometimes we try and polish something for the first release, but we always set a limit to that - if it's not in production, it's not shipped, and we will forget about it amongst the 23524 other things going on in a given week. Therefore, we usually set at least some internal goal of "good enough" and then ship. It just so happens one of our founders really likes digging into design.
Also note, this is an iPhone app, not a web application. Very different rules apply here, so you can't just slap Bootstrap on your UI and hope for the best :)
You seem to be describing, basically, overengineering applied to visual design.
For a developer, an example of equivalent behaviour is being overzealous about a specific programming paradigm. Things that can't be directly quantified in business terms (unlike "response time").
IMHO, it's about pragmatism and business sensibility versus artistic perfection. And it applies for both worlds.
An argument from a more business-oriented visual designer could be, for example, about how some button color can affect conversion rate.
The example about Google engineers "thinking like designers" is actually an example of "engineers thinking like engineers thinking about engineering a color choice" which the author is calling design. This is embarrassing. Engineers shouldn't think about design. Remember Douglas Bowman? http://stopdesign.com/archive/2009/03/20/goodbye-google.html
People want to use things - i.e. products, digital or otherwise - with style and performance. People, real people, don't give a rats ass about computer science or design - they just want the product to do something for them and they want to look cool doing it. With their expectations of performance aside for the moment, there is nothing cool about engineers "optimizing" style.
In my experience, multi-disciplinary people of any kind work better than those who aren't. Such a rare and precious thing to understand the boundaries between fields and how connected they really are...
Currently dealing with design and usability experts that are spending a lot of time building things instead of shipping and trying out different approached.
There seems to be an aversion to A/B testing because that would clearly challenge their title of "experts".
Once you get down to a functional and complete design, it's useful to A/B test details to optimize.
But it's nearly impossible to design something using an A/B test. Design simply does not work that way—it is not an evolutionary process on three variables, initially whether you believe in it or not, it is an art and as such takes in thousands of variables in thousands of forms and outputs something that works. That's the job of the expert—at the beginning, they are using their internal A/B test to produce something they know will be successful in the grand scheme. Give them a chance, please.
Although these changes may seem like an unnecessary level of attention to detail, its important to keep in mind that this would be a very minor change to make design and engineering-wise. We're not talking about moving around elements or re-doing the entire design, just changing some colors/gradients. In my opinion, the little bit of extra effort required to put this level of polish on a product is completely worth it.
Most problems with perfectionism in design and engineering come from people making bad decisions early on in the design/development process and not realizing that something is fundamentally wrong until much later on--when its much harder to fix.
Notice how the edges are now fuzzy? On the buttons, on the edge just below the map, on the cog. That sticks out to me personally on this monitor here, and I tend to find differences like becoming even more noticeable when looking at the phone with it's hi-res "Retina" display.
They may not be crazy; they just notice different things. :)
> *"A design can be wrong. The entire thing can be wrong, parts can be
> wrong, or even a tiny, 10x10 pixel area can be wrong. Not, "I think it's
> good but it needs improvement" but flat-out wrong. 1 + 1 = 3 wrong. A
> spelling mistake in a book wrong. A syntax error in a code file wrong.
> It's not an opinion, it's not a matter of subjectivity, it's a fact: a
> design can be wrong."*
I'm not a visual designer, but I do see the difference in crispness between the two stadium images, and I think the improvement in the sharper one is non-trivial.
However, I'm frustrated with designers who associate thoroughness with being "pixel-perfect". Pixels should not be the focus. We live in a multi-res world; different people have differing visual acuity and varying ppi screens that they hold at varying distances. Being user-centered means accounting for all that variation, not optimizing individual pixels for your super-designer-vision. Just use vector art instead.
I hoped that the retina iStuff would finally break designers of their pixel-focus, but it seems that it's just become a way to obsess even more about pixels.
That's because pixels are important. The non-trivial blurring you see is the result of the edge of the image not being aligned with the edge of the pixel. the screen has to anti-alias it onto the subpixel, and it looks shitty. High PPI screens mitigate this somewhat, and i'm sure every designer would love to get away from using pixels but the results just aren't good when you do.
Vector art produces bad results. So, no thanks. The problem is the ridiculous number of varying Android resolutions. There, we have to be flexible. But still not going to use vectors.
Well, on mobile it can be hard to quantify and connect design to value. On the web it's a different story.
There's nothing wrong with beautiful design as long as you are willing to accept the fact that at one point it is serving art and not business needs. And that's OK.
If the requirement is to strictly serve business needs, then you have to A/B test, generate numbers and go with what optimizes conversions or whatever you are after. People react to what they see in amazingly different ways. I don't think anyone has a canonical "manual" for what will please most people or what will compel most people to take a given action. I mean, look at Craigslist!
as a designer, i wholeheartedly agree with his points on the obsessive strive for pixel perfection. no one cares besides designers. or at least no non-designer i've ever asked.
it's becoming a problem. look at dribbble. countless designers would be more likely to obsess over a single misaligned pixel rather than focusing on far more impactful improvements to the user experience.
a pixel perfect button in the wrong spot will always perform worse than a misaligned button in the right spot.
aren't both of these sample images scaled down? Unless one sees the actual raw screenshots (640x960 and 320x480) one can't really tell if there are inaccuracies or not.
Also, if the @2x version has 1px features then these will definitely become blurry when scaled.
Maybe I am the crazy one, but it feels like the real issue is that design practices are just less practical (mature?) than software engineering ones. We both strive for perfection and idealize great work. The difference is that few places allow for that kind of waste in their software departments because history has shown us that endless supplies of time and money just result in waste and churn, not significant changes in quality.
This may have been said before, but I am posting anyways since there's so many comments here and I don't have time to read them all.
I think I have a way to explain why pixel perfection is a very good optimization that caters to more of a a developer mindset like yourself; it comes down to image compression, and specifically PNG compression.
When it comes to UI elements, the fewer colors you use, the better. This means avoiding things like gradients, or unnecessary colors can have a major impact on file size. It's also the 'art of design' to manage to create a beautiful design without a lot of crappy and needless 'veneer'.
I don't know the specifics of the PNG algorithm, but it can do an amazing job at compressing an image if it's made up of few and often repeating colors (typically it's terrible at photographs, however).
When you apply a scaling algorithm (as exemplified by the post) other than nearest neighbor, it tends to create a lot of intermediary colors that end up hurting the size of the image.
Looking closely at the borders of those buttons, that blur is going to end up adding to the file size because it adds colors that didn't exist before. If you properly 'scale' (which sometimes requires a redraw at a smaller size to get it right), it can have a huge impact (sometimes as much as 2x or 3x).
Oftentimes you can get away with it from a 1/2x scale fairly easily, but you have to remember there are many android devices at a 1.5x scale, and that can sometimes require completely new rounded corners that take advantage of that pixel density.
This is of course anecdotal, but it's not as simple as 'looks' even though I could immediately see the differences between the properly and unproperly scaled images.
Interesting screed. I've observed that some folks "see" more than others (my daughter for example notices very minute details in things I completely miss) which may explain most of the observed 'crazyness'.
There seems to be something similar to the 'uncanny valley' where something nearly complete becomes more obviously incomplete before being complete. (I know how crazy does that sound!) But an example might help, if you straighten up a room, it goes from fully chaotic to less and less messy until the 'organized' parts start dominating the scene with respect to the messy parts. Than as you approach completely organized a small bit of chaos sticks out more and more. Until that is eliminated and everything is in its place.
Different folks have different tolerances (I know, Doh! right?) People who consider themselves designers have worked hard on being able to see where something can be improved visually, so they are much more likely to see issues that detract. Non-designers just don't see things the same way.
I 100% agree that rescaled bitmap will almost always be an ugly bitmap and certainly needs to be fixed, but IMO it is a crazy idea to fix such problem with manual pixel-wise tuning. This something machines should do while rendering vector input, otherwise it will be a pure waste of energy that will never scale.
Precisely; hinted, procedural vector graphics are this panacea (see SVG's shape-rendering and media queries). There is significant initial cost to create a library of widgets and icons, but they are perfectly reusable and thus overtake a designer pixel-perfecting every screen to all target devices fast.
This really hits close to home because I do often wonder if it does "matter". When the audience do not appreciate the three hours I spent on the title's kerning or decision on the thickness of the boarder or the difference between ultramarine to navy, I do feel a sort of defeat that can result in a "why do I bother" attitude. But the next time, I would still put in the effort because as insignificant as it is, I do notice it and I believe it does make an impact in the viewer's pleasure. Design is a lot of the time a struggle between satisfying the employer and holding onto the designer's own concerns. And even though most, like the author, might not see a difference or even undermine what the designers hold dear, there are people who will notice, if not appreciate the details.
These types of optimizations can be crazy only if they are relevant to a SINGLE INSTANCE.
If the designer figured out a better way of scaling an image, that he will use EVERY TIME moving forward, he has just improved himself and/or his trade.
Even if they don't "capture" the process in an obvious way, they will often capture it in the form of experience.
In the rare case that it does not lead to a better process or experience AND is not noticed by the end-user AND is not noticed by the employer, then you can argue that it is indeed 'crazy'.
Or you can call it self-satisfaction, pride, etc... :)
The 'scaling problem' and 'aspect ratio problem' are both ancient and well solved - I can't take anyone seriously complaining about iPhone form factors - its just a new problem for them because they are utterly inexperienced and new.
What I find interesting is that the example you give has many more ugly design problems than the minuscule changes from compensating for the scaling. Look at how poorly the text is arranged in the buttons for instance... I also hope the colour banding is an image compression artefact and not in the actual app...
Think about it as code formatting. In order for your code to be extensible and readable you need to make sure that you are using the right fundamental indentatation, naming convention etc.
Where you look at the buttons individually, the designer looks at the style. The sum of all the items styled in a certain way.
The real question is not whether designers go too much into details but rather when they should and when they shouldn't.
perfection is the enemy of doneness.
I agree that Obsessing over every pixel achieves the highest quality of work, but it carries a high risk of the work never getting finished. I think both designers and developers can obsess over stuff like this Ad infinitum, and if they have the budget to do so, good for them.
I however, would much prefer having a project that's finished rather than perfect.
I haven't read anyone noticing that developers lose countless hours fighting with badly crafted PSDs like the one shown in the article, just to extract proper assets that keep their code tight. Think pixel fitting, but also dimensions consistency, color consistency, etc. Off-by one/three/eleven pixels are a plague. Save money on the design: you may well increase your development costs.
Sure understanding the relationship between good design and how it applies to different technologies takes time. Whether that be resolution independence or color correction, but once you've got your head around the "working out", there's no reason why you shouldn't strive for perfection.
Achieving pixel perfect design nowadays doesn't mean you have to go insane in the process.
It's about perception. The slightest imperfection can be glaringly obvious to one type of person, while another will never notice.
I am not sure if that kind of "eye" can be trained or not, but I know I have it, and that the slightest misalignment or aliasing will jump out at me and I have to fix it (if I can help it).
But that's not design. That's technical details. Let's out it this way...we didn't learn how to smooth pixels at my art school which is jsyt about the best place you can go for a degree in graphic design in the country.
A good design school doesn't make you a good designer. I've seen SCAD and RISD grads who couldn't design to save their life. With all design, it's about understanding the medium. For a lot of designers, that technical detail is what makes them stand out from the rest.
Are people who think designers are crazy, crazy? Not to be a dick but the other day with the WP-Svbtle thing you demonstrated you don't understand principles of design. That's cool; you don't have to.
I'm not a designer but I think that the left one has been scaled down. The borders of the buttons are less crisp than in the right image, that have become pretty blurry. Not a big difference, but it's there.
the main problem in this example is that the designer is worrying about the scaling of the graphics, rather than the fact that the stadium map and ticket listing are severely lacking any sort of visual association.
"pixel perfection" trumped actual ux improvements.
For me this is not a matter of perfectionism but knowledge. If you know something, you would like to apply this knowledge. If you don't, you wouldn't care that much or will think that is irrelevant.
How can you not notice the brighter orange? It draws your attention / jumps out at you / causes you to notice it - when before it was equally as bland as the other colours. The brightness of it comparatively causes you to notice it, note it as more importance, as you skim down to see what action options you have on screen.
The article uses a good example of designing things for other designers. The difference doesn't improve the product in a way that benefits the user. It's why I fail to understand designers sometimes.
On the other hand, I'm sure designers would say the same complaints about source code optimizations. But I hope we can agree it's about personal satisfaction, and that there's not necessarily anything "crazy" about it, it's just the sort of passion that results in quality.
Fatigue in the short period that the user will have the app open? They'll open it only while they're doing the specific task they opened it for. This app isn't for the gawping.
But those who care about the details achieve truly high quality results overall. It extends to all areas of the design, not just to the parts you can't see.
In the movie "Who Framed Roger Rabbit," there's a scene in a dark room where Roger Rabbit (an animated character) flies across the room, knocks a hanging lamp around, and the lighting becomes so dynamic that all the shadows move around including the animated character's shadow. Here's the scene in question: http://www.youtube.com/watch?v=_EUPwsD64GI
This was such a small detail that it would have been forgivable if the animators had left it out entirely: if they had not moved the lamp, kept the shadow steady, no one would have really noticed the difference. It would have been 100 times easier to animate and the effect wouldn't really have been that different.
But they did it anyway. The term was later coined, and "bump the lamp" is used throughout Disney (and probably other organizations) to mean something akin to "go the extra mile"—but I see it as having a special significance to design.
You're right, most people won't notice. By that logic, you could cut corners a lot of other places too. You could be lax about button colors matching exactly, or per-pixel sharpness on the map and buttons. No one would probably notice.
But if you go for every detail like it was the most important detail, you have the possibility of reaching a level of design quality that is superlative, and some people will notice. Others will not notice directly, but will see that the piece exudes style and quality subconsciously, due to the attention to small details. If you carry this into other areas of your work—programming, customer service, market strategy, marketing, and more—then you have a chance to create something of true quality.
If you don't pay attention to detail at that level, well, you might have the chance to actually get something done. Yes, it's a balance, like everything else. But you have to know that it won't be quite as good, and understand that yes, you are sacrificing something, even if you can't see it.