Designing a good color picker
There are a lot of things to think about when it comes to color pickers. Is the color arranged in a cube, a tringle, or a circle? Are there values for RGB and CMYK? What about HSV and HSL? What gamut do they display? Is there a hex value that can be easily copied between different tools? There are so many features you can think of when creating a color picker.
When folks think of a color picker, I usually see them gravitate towards something like this:
There is a cube, a bunch of values, something that displays the currently selected color as well as the previously selected color, and a list of ‘last used’ colors. There are many different UI configurations for these elements, but generally the core concepts are the same whether it is shaped like a cube, a triangle, or any other shape. You never have to search far for a color picker either, as even when you search Google for a color picker you can find one right underneath the search bar:
There are some other neat elements that color pickers sometimes add, such as Adobe’s color picker giving you 9 different preset ‘Color Harmony Rules’ that give you multiple colors next to the one you picked that may work well together:
So, there are a lot of features we can think of when designing a color picker! Which ones will make for the best experience? To find out, we should look at the workflow wherein the color picker is used. The color picker is a really neat and straightforward example of a tool that is used in conjunction with other tools: The color picker itself is not used to perform a main task. Instead a color is needed in an other task, and the color picker is a tool on the side to accomplish finding a color for that main task. Then when a color is found, the user returns to the main workflow they were doing. How does that work in a large project? Does anyone just select any kind of color for those purposes? How many users actually have to select a brand new unique color? Is selecting ‘a’ color the task the tool needs to accomplish? Or is selecting the ‘right’ color the task the tool needs to accomplish?
For example: You have an art director or art team setting up the colors that everyone in the company or project should use. That means the color picker should allow for them to select any color at any time to make sure they can quickly test what colors work well. And it also means nobody else in the company should have a color picker that allows them to select any color they want. Instead, they should be using the colors the art director or art team have selected for them. If anyone can select any color at any time, sooner or later you will notice the wrong colors are getting used around the project, and large amounts of time have to be spent fixing those issues. If that is your use case, then the priority is not on the art director or team being able to select any color they want, but rather on making sure everyone else uses the right colors at the right time.
So the question moves from “What is a good color picker?”, to “What is a color picker used for?” and “What does it need to support?”. If you are making a color picker for a large in-house tool, then for most use cases the color picker isn't there to grab any color. Its there to grab the right color.
If the color picker allows everyone to always pick any color, then you have only added more work for others to clean up later, and not helped a product get shipped on quality and on time. If anyone can pick any color then there will be a texture somewhere with a slightly more light hue of blue, instead of the blue that is required for that use case. Someone will notice that error in color, sooner or later, but by then it will have taken a lot of effort to both notice and fix. So does your color picker really need all that ‘classic’ functionality of a color picker? If someone really wanted to grab a particular color, we have already seen that there are multiple good online solutions that will give you a hex, RGB, CMYK, etc, for all your needs. If everyone in your project needsto continually grab unique colors over time, as everyone is a painter, then yes you may need a fully featured in-house color picker. However, if instead you have a lot of users who should use what the art director and art team have decided should be used, then what you need is not a fully featured color picker. What you need is shared palettes.
Shared palettes
More holistically, especially for bigger projects, color pickers need a way to for a ‘profile’ to be attached to them. Either with the project having a single profile, or multiple profiles for various departments such as level design, art, lighting, UI, etc, depending on how complex the content can get. The power of the tool here is to allow all the departments, and the folks within them, to have the right color ready at the right time. Without having to find it, create it themselves, or having to copy and paste RGB, CMYK, or hex. Copy and pasting those will go wrong now and then anyway when they accidentally copy and pasting a wrong value between Slack, email, or even a notepad. This then requires potentially costly fixes and QA to make sure everything is colored correctly. We are all human, and make mistakes. The answer is not to get mad at the user for having made a mistake, but to improve the workflow.
Many color pickers allow you to ‘Add custom colors’ or ‘Save colors’ in some way, however those are often local only. From my experience working on big projects with color pickers, there are certain established colors being used. For factions, tribes, races, locations, characters, etc, that all have a particular established set of colors that players need to be able to recognize. Those palettes should be included and owned by someone, and saved to whatever versioning system you have. That way, everyone always uses the correct colors whenever they need to color something. The chances of someone needing to use a brand new color, and really use that amazing UI of a wheel, triangle, or box, to its full extent, is usually rare unless they are (tech) artists.
If you have specific colors referenced as a variable then the workflow gets even more powerful. That way if a color were to ever change (and let’s be honest: They will) all the places where the color is used will automatically update. So if an art lead changes a factions color from blue to teal, or red to green, it auto-updates all those cases. That saves a lot of time and headaches everywhere around the project, and solidifies the importance of a color picker in resolving issues instead of creating them.
So we can see that the color workflow gets more powerful even if the color tool did not get many extra features. Filling up a color picker with more and more features is a lot of programming work too, and there is never enough time to do everything. So why not make less features for the color picker, and instead make a powerful and useful workflow for the project, instead of for the tool? Especially if you have data on whether users often need to make and set unique colors, then you may get away with simplifying the UI way down, and not even showing the triangle and wheel to most users. Out of sight, out of mind, no need to worry about it.
What is the tool, and what is the workflow?
The core here is to understand the difference between features on a tool, and the workflows the users need to complete. All of the features at the top of the article sound really neat, and they could make for a very powerful color picker tool. It is easy to fall into the trap of thinking that a powerful tool must be helpful. It is also very easy to argue for all the amazing features a color picker could have. Everyone in a design meeting will nod their heads and say those features sound neat and helpful, because they do sound neat neat and helpful. At the same time it is tough to argue against neat features, apart from saying it will take more time to write the code.
Instead we should look at how a color picker is used within a large project, and what features it needs from that holistic perspective. Then we will find out much less work may be necessary. We do not have to spend a lot of time making a color picker with a big feature set. It means not having big and long meetings about whether to make the color picker square, triangular, or round, or what values are visible. It means less UI complexity, less code to maintain, and less effort to make an MVP. Shiny features are neat, but sometimes those features can end up creating more work for everyone in the project, instead of less.
What are the main takeaways here?
Be careful of feature scope creep. Features are shiny, but do you need them?
Always look at what the user is trying to get done in the bigger picture. Keep asking: Why, why, why, why, why?
Sometimes giving the user a lot of freedom is powerful and allows for creativity. At other times you are facilitating situations that are costly to be cleaned up later. Guard rails can be useful, even as just a warning.
Find out where the tool you are working on is located within workflows. Is it used on its own, or in conjunction with many other tools?
Can someone achieve the goals they have with a free, unrestricted, and publicly available tool? If they can make use of those, it may help you get the design and programming time to work on other more important and unresolved tool needs instead.
Thank you for reading! And thank you to The Toolsmiths Discord for having a fun discussion on color pickers in their UX channel, as well as David Lightbown for his feedback. If you enjoyed this post, you can find my talks here, and my other posts here. You can also subscribe below to get updates when a new post is published.