HHGTTG. Excellent reference, if you're going to spend time on picking the 'right' colors rather than just any set of half decent colors and then move on you might miss out on that important little thing called functionality without which it really doesn't matter what color it will be.
Once you're established and you're tuning the last 0.3% of the market that you might catch if only you used the 'right' colors you can spend time on this.
It's another nice example of premature optimization.
Rational, practical people have always been quick to dismiss aesthetics in favour of functionality, but it turns out it's actually pretty important. People will use the ugly, functional thing if they have to, but they'll leave if they get a chance. I think this dynamic alone explains a large part of the success of a number of SaaS apps priced as is often advocated here to allow individual managers to buy it on a corporate credit card without going through procurement.
As an extreme worst-case scenario, consider post-war high-density architecture. With a few exceptions, they are various degrees of slum today, not because they lacked functionality (that came later when they were left to deteriorate), because anyone with the resources to left.
Back to software, I have had the pleasure of replacing a good number of ugly but functional line-of-business systems, and the eagerness with which users will adopt the new thing, almost entirely because it's pretty (it often doesn't much new for many users, the main improvements are on the backend and for power users), always catches me a bit off guard.
On the personal level, I've found that investing a bit of time up front in making a new thing pretty increases my personal level of happiness working on the thing, even if I end up changing entirely away from the original look as features evolve.
I've seen the opposite as well: ugly looking terminal or DOS based but very productive software was replaced with spiffy looking windows or web based software that was slightly slower or unable to keep up with the type-ahead of the users and this led to huge disappointment.
I'm firmly believe if it doesn't work it doesn't matter how good it looks and if it works but looks bad that's better than the reverse.
Then once you've figured out what to build you can always make it look pretty.
It's not a dichotomy. I'm arguing for the importance of both, not either-or. Obviously, a thing that doesn't work, doesn't work, regardless of how pretty it might be.
> Then once you've figured out what to build you can always make it look pretty.
That's a lot harder than it sounds. No, of course you don't commission a big fancy design before you know what the thing should do, but you equally can't just build an ugly, but functional thing and throw lipstick on it five minutes before shipping (or after - activities schedules for when the thing is 'done' have a nasty tendency to not happen). Both, in parallel, at its time, not either-or.
Terminal/DOS-based software isn't ugly, it's just a different interface (GUI vs. non-GUI).
Of course some technical people that know what they're doing will enjoy using the command line because you don't have a GUI that gets in the way, but using this fact to "prove" that people like ugly software better doesn't make sense—it's just a bad example.
I worked for a very large corp that wanted to convert an application that we used to process applications. It took less than a second to process 99 percent of applications. They wanted to switch from a cli app to web. I told them they were nuts. We could currently process the days queue in minutes. Sure the company could have loaded all the data and used js to feed them out quickly, but the programmers had no idea what we were doing and certainly wouldn't have designed it correctly. The company wasn't changing it to be trendy, they were changing it to make things easier. It would have had the opposite effect.
Not blind, but I had eye surgery about a year and a half ago, followed by a recovery period about 4 weeks longer than I was told to expect, during which I came to appreciate things like contrast. Not coincidentally, I also realized my software was literally* painful to use for someone in my condition.
I have learned to give a shit about color choices.
*That's the literal 'literally', not the figurative one.
It hugely depends on the target user group: admins don't mind about an 'ugly looking ... but productive software', but non-IT users mind a lot, and for them it has a significant effect on usability. It can only be '_very_ productive' for the target group, when it is also well-designed for them.
The legibility tab is more generally applicable though. " tuning the 0.3%" could be significant then that 0.3% are people with significant vision problems.
You still don't want to be spending more than a moment on that in early design, but with a tool like this covering the issue might only take that moment so you don't have to make alterations later when early design decisions/accidents are baked in and harder to change.
Yes, and it would be enough to have one set of styleguides to cover all apps. In fact, I would very much prefer that. All the 'cool' looking stuff can be extremely confusing because you need to re-learn at least that part of the UI over and over again. It's a kind of mental form of lock-in.
Try to be serious. Wine that costs 1000's of $ per bottle is in exactly the same bottle as wine that costs next to nothing. The only difference is the label.
Of course there are marketing whizzes that package crap wine in fancy bottles to sell it at inflated rates but that's nothing to do with what I was trying to illustrate.
Winebottle: glass enclosure usually topped off with a cork, usually made of green glass. That there is wine that is so cheap it isn't even sold in bottles is an optimization, the fact that there are very fancy bottles with wine that usually isn't all that good is marketing.
You're implying that if one uses the color tool, he's going to spend hours playing with it and forget about implementing important features. The tool will save you time instead of waste it, since you don't have to make up a color combination yourself, giving you more time for implementing stuff.
I also disagree than making an app look good will make it more appealing to only 0.3% of users. People are very design-oriented nowadays, and non-technical people will judge the quality and reliability of an app mostly by the way it looks. Personally, I _always_ try the better-looking app first, and if it works I stick with it and never even try the ugly one.
"Ah," said the marketing girl, "Well, we're having a little difficulty there."
"Difficulty?" exclaimed Ford. "Difficulty? What do you mean, difficulty? It's the single simplest machine in the entire Universe!"
The marketing girl soured him with a look. "Alright, Mr. Wiseguy," she said, "if you're so clever, you tell us what colour it should be."