Home » Blog » Why Programmers suck at Picking Colors

Why Programmers suck at Picking Colors

October 3rd, 2007

There is one simple way to tell if a user interface was designed by a programmer: the colors suck.

For the longest time, I had that problem myself, so much that I decided to go grayscale (like this blog) and focus only and exclusively on brightness and contrast.

This turned out to be a great strategy: picking colors from a 1D grayscale was way easier than picking it form a 3D solid cut up in 2D rainbowy slices. If we keep the background fixed (doesn’t need to be white!) then we just need to pick the right amount of contrast that we want. This is a very simple and straightforward choice.

Let me repeat this because it’s very important: contrast is the basic building block of UI design. Two pieces of information with the same contrast against their background will be perceived at the same importance level (all other things being equal), while more contrast identifies more importance and less contrast identifies less importance.

It’s trivial for programmers to understand this and the resulting experience is both pleasant and rewarding for them as they never feel they are making random choices or guesses: they need strategies and algorithms.

When colors (or ‘hues’ in proper terminology) enter the picture, the average programmer feels lost and for two main reasons:

  • There is no easy way to estimate the ‘energy contrast’ between two colors, also because the background heavily influences the human perception of color relationships
  • There is no strategy on picking colors that ‘go together well’, especially if the color picker gives you 16 million of them

The very first huge mistake that programmers do is to think in terms of RGB: RGB is the result of the discovery that a lot of the colors that humans are capable of perceiving can be generated out of the combination of three light sources, one red, one blue and one green, at different intensities. This is how pretty much all screens and projectors work. Unfortunately, this is not how your brain works, it’s a technological artifact and it’s mostly due to the physiology of the color receptors in the human eye (and not to the physics of light itself!).

But we don’t see colors we our eyes only, there is a lot of post-processing that our brains do on top of the ‘raw’ signal that the retina’s receptors send over to the visual cortex.

A better way to model color is the HSV color space (sometimes called HSB: hue, saturation and brightness): most color-picking dialogs of graphic programs have an HSV mode and it’s clearly much better than RBG because it allows you to easily go back to the ‘linear contrast’ strategy by just changing the brightness and keeping hue and saturation fixed.But now you’ve turned a grayscale UI into a monochromatic one, not that much of an improvement.

So you’re designing a UI and you get to the point that you want to differentiate parts of the screen that have the same importance (ergo, should have the same contrast) and you go back to the 2D problem since you have two nobs: hue and saturation. Which one to turn?

So you start turning at random hoping to find something that ‘goes well together but has the same contrast’ and, with your surprise, you find out (after years of doing this) that changing hue and/or saturation alters the ‘energy’ perception of that color. So, while you turn your hue and saturation knobs, you’re screwing up the contrast and it’s very hard to understand what to do about it other than sampling at random (which is a very frustrating strategy for algorithmically-oriented minds).

Here is where a little more advanced color pickers will use a fixed hue angle for you to pick palettes: if you start with a color, you go x hue degrees more and less, with the same saturation and brightness. The resulting color schemes are not horrific (as they would if you did the same operation in an RGB color space, say), but they feel mechanical and soulless.

Then came the ‘color loving’ web sites, where others, who are good at this in some mysterious and magic way, upload their own ‘color discoveries’. Sites like ColorLovers and Kuler do just that.But while I’m an avid user of those sites, using other people’s palette’s without any idea or strategy on how to improve on them feels like admitting defeat.

So, here I was, completely defeated and basically ready to give up and admit that my brain just doesn’t work that way, when I came across a web site on color theory for UI designers at the NASA Ames Research Center.

And it blew my mind.

The site features a lot of information about color theory for UI designers (which is so so very different than color theory for desktop publishing, for digital photographers or for video editors) and, best of all, a color-picking applet that features a color space that I never seen before: the Munsell color system.

The Munsell color system is a color space that specifies colors based on three color dimensions, hue, value (lightness), and chroma (color purity or colorfulness).


  • the color space is discrete (making picking easier)

With the help of such tool, picking colors for UI design becomes a very natural process (unlike all other color pickers that I’ve tried previously): lightness still is the principle axis, guided by information importance and relevance, hue can be sampled out of personal taste (or existing palettes or real-life scenes/pictures) and the chroma can be sampled to obtain the desired value of differentiation (one can also use chroma to indicate sub-relevance but not everybody has the same ability to perceive chroma differences so this is a more dangerous practice).

Overall, the discovery of the NASA color picker has changed my ability to designed colorful user interfaces without feeling like I’m copying somebody else or I’m just lucking out. I’m never going to be a great web designer, but understanding that tools were part of my problem has been a tremendous help in gaining confidence: I hope it will do the same for you.