I asked a question here to make a recommendation on an upgrade on color palette selection.

We have a dashboard that has many boxes displaying text. You can change the color of the boxes and the text as you want.

One of my suggestions was to replace the color palette from a full RGB selector to a smaller selection of colors, as the user least likely is going to differentiate between something like:


download bmml source – Wireframes created with Balsamiq Mockups

...if they're not close enough (Yes, those are two different shades of red).

Another idea was to limit the text/background combinations to ensure good contrast happen


download bmml source

My colleague told me that "the user should be able to pick black background on black text if that's what he wanted", I replied that I didn't agree. Specifically having the cradle example given in this TED video from minute 6:00 to minute 9:00.

The video says:

You want to make it hard to use wrong. You want to make the right way to use it the easiest way to do it.

So my question is:

Is it better to Limit the user in the color choices they can make in order to ensure a better user experience? (For a reason I cannot stop thinking of Steve Jobs right now).

BONUS: Citing Hick's Law would really make me happy (if applicable). I want to see what's the impact on hick's law on a 32 bit color palette :)

  • I've edited your question slightly so that it focuses more specifically on the color choice limit question, rather than just about limiting the user in general. That would be a bit too much of a discussion topic rather than a specific Question than can be Answered. (i.e. keeping it focuses on a Q&A). Hopefully this still keeps the spirit of your question though.
    – JonW
    Sep 10 '12 at 8:57
  • Hey @JonW, I was actually more interested on the other topic rather than the color one... I think that the color example provides a good analogy for the whole topic.
    – edgarator
    Sep 11 '12 at 1:58

Allowing end-users to modify the UI colors leads to people using the Hot Dog theme in Windows 3 or whatever that polka dot theme is in SharePoint.

It's a 'ooh neat!' feature that provides little to no value and, often, is a huge detriment to every person that has to use the site.

I could see offering a few well-curated and designed options, but letting people randomly do as they wish in most cases will lead to eye-bleeding results.

  • I would agree with this if offering the full color pallette wasn't the default. If you have to go out of your way to limit the choices, why offer a choice at all when there is little value?
    – JeffO
    Sep 11 '12 at 13:07

It depends what's the point of different colors: is it only for personalization, eg. the dashboard colors are not designed for a public audience, but rather for yourself?

In case it's a personalization, the next question is about amount of dashboard boxes: what's the likely amount you'll have?

It can be that if you have a hundred boxes, you want to have similar background, different foreground to have a sub-grouping, while if there are only about a dozen or two, it's enough to have groups based on a single colorscheme.

In case the former, you better give fine-grained access, albeit it's enough to do it with "crayons": OS X gives you the ability to choose from a pre-defined palette in an intuitive way:

OS X crayon color chooser

Do this for both colors.

In case the latter, it's better if you provide some pre-built schemes, a "theme-chooser": show an example widget in each colorset with a name.

two themes for a theme chooser

two themes in a theme chooser: I'm pretty sure MS Word has some better examples...

In case it's for a public audience, it's better to let users have fine-grained control. That means, a full color palette chooser for both colors...


Let them choose the background easily with a limited initial set of colors, expanding to unlimited - and auto-toggle (based on color math) the foreground color between a light and dark to give good contrast.

Balsamiq does this automatically. Below I created two buttons - when I changed the right button background to red, it automatically toggled the foreground text to white. An ambitious user could change the text color to fuchsia, but most users will likely care most about the background color.


download bmml source – Wireframes created with Balsamiq Mockups


I think you're on the right track -- a limited set of options is probably what I'd go with. (Unless your application is some kind of color picker or design thing.) In my mind, the main reason you'd use a color picker is when the user needs to put in an exact color. This is probably not your situation, so I'd go discrete.

Assuming you're not making the next Photoshop, I would make enough discrete options to cover your uses. That is, if the average user needs to use ~10 different colors, give them somewhere between 20 and 30 and see how it goes in user testing.

Use a paper prototype to explicitly test some key scenarios that require a lot of colors. See how users react.

And, I'd probably stay away from black on black. Making options like that just doesn't seem to make a lot of sense. (Unless your users explicitly want to hide things or make them confusing for others. Could be interesting for a game, but probably not what you're after.)


If you limit the options, you have to cover all use cases or you'll fail some of your users. How confident are you that your options cover all use cases?

Some use cases you might not have considered:

  • photo-sensitive: black/white and white/black are actually terrible for some users; it's too high-contrast/bright. Those users will need shades of gray or brown/beige instead. If you hard-wire your text choices to black/white and offer, say, 16 background colors (half light, half dark), that won't be good enough.

  • color-blind: are your reds, greens, and yellows really as distinctive as you think?

  • categorization: as pointed out by Aadaam, users might be attaching semantics to similar-but-not-identical colors, and if you take away the similar colors that won't work.

  • consistency with other applications: your application is not the only software the user uses; if you provide similar functionality to some other application that he also uses, he may try to customize the two applications in the same way for easier transference.

Given that you already have the more-permissive color scheme, the question should not be "why should I keep it?" but "why should I remove it?". If the user cannot harm anyone else and can potentially benefit himself with more color options, why not let him do that?

  • Fair points, but depending on who it is that's building the application, isn't it their job to ensure the limited choices they give the user are full accessible as much as possible? That's part of the 'joy' of the work - trying to figure out how a Magenta and Green colourscheme the client provides can be made usable and sensible in their website while still being on-brand.
    – JonW
    Sep 10 '12 at 16:05
  • I'm suggesting that you'll always miss something because users are complicated. The common approach of providing, say, 16 pre-chosen colors and a color wheel for fine-tuning seems to work well; choose those 16 colors well and most of your users will just take those, but if somebody does need more control it's available. If you're building an application from scratch and the color wheel adds too much complexity that's different, but in a case where you already have that, why not continue to make it available? Where's the harm? Sep 10 '12 at 17:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.