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.
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.
>> 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).
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.
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.
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. :)
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... :)
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 :)
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.
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.
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.
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).
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.
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.
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.
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.
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...
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...
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.
155 comments
[ 3.9 ms ] story [ 207 ms ] threadIf 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.
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.
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.
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.
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).
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 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 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.
"pixel perfection" trumped actual ux improvements.
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. :)
Of course, I still watch analog NTSC on a CRT TV, so what do I know about image quality?
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.
It doesn't make them crazy necessarily, it just makes them not programmers.
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... :)
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.
A/B testing is useful, of course, but the results can only ever be as good as the options you test.
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.
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.
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%.
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.
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.
If you are not in that situation, could it be because you weren't perfectionist enough in the past?
E.g Nokia vs Apple.
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.
SUPER IMPORTANT!
Design is not art in and of itself, but you can't talk about one, without talking about the other.
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).
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 am a lead designer, and I know that not every piece needs to be a masterwork, but ever piece of software does need to ship.
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 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.
Basically "I completely agree with you, but wish to do so in a humorous and sarcastic manner." Apologies.
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.
It sounds like they optimized for the wrong thing.
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.
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.
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.
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.
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.
Try again.
Also, if the @2x version has 1px features then these will definitely become blurry when scaled.
Even so, when held at arm's length I'm doubtful of how noticeable the differences are.
I know of no-one, tech or non-tech, that holds their phone at arm's length. Most hold their phones much closer.
http://dcurt.is/pixel-fitting
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.
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).
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 :)
Your idea of "good enough" almost certainly isn't. Users do notice even if you're too pigheaded to admit it.
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.
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.
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).
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.
I will notice pixel perfection every time. So thank you all for the attention to detail.
But this is just trolling man.
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.
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...
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 engineers who think a little bit about design work better with designers than those who don’t.