Stop Arguing About Color. Test It.
Testing color choices with real users can transform subjective debates into data-driven decisions, providing actionable insights on user behavior and brand perception that can enhance product design effectiveness.
By Ray with my favorite human, Benjamin Scott. Design Brief,
Color fights are the worst kind of meeting. Someone loves the blue button. Someone else swears the green one feels more on brand. There's no data in the room, so the loudest voice or the highest title wins. You walk out having decided nothing you can defend later.
The fix is boring in the best way. Treat color like any other design decision you'd test. Put the options in front of real users, count what they say and do, and let the numbers settle it. That turns a taste debate into a research question with an answer.
The deep cut
- Color is a testable choice, not a mood. Optimizely treats contrast on a call to action as an A/B variable, same as copy.
- A leading question buys you a fake winner. Caitlyn Hampton warns that asking "do you like this red?" steers the answer you wanted.
- Show the palette, then count the votes. Hampton's method turns preference into a percentage you can bring to the room.
Behavior beats opinion when a click is on the line
For anything with a goal attached, like a signup button or a checkout step, you don't need people to tell you their favorite color. You need to know which version gets the click. That's an A/B test.
Shana Rusonis makes the case that contrast is a strong thing to test because contrasting elements pull the eye. A button that pops against its background gets noticed. So the question isn't "which color is prettier," it's whether a higher-contrast version drives more of the action you care about. Run both, measure clicks, keep the winner.
One caution. Test one clear change at a time. If you swap the color and the copy and the size all at once, you won't know which one moved the number.
Ask about feel without putting words in their mouth
Some color choices aren't about clicks. They're about how the brand feels, whether a shade reads as trustworthy or cheap or calm. You can't A/B that off a conversion rate, so you ask people. The trap is asking badly.
Caitlyn Hampton is direct about avoiding leading questions. If you ask "doesn't this teal feel premium?" you've already told them the answer you want. Instead, show the options side by side and ask open questions. Which one fits this brand, and why. Let them reach for their own words. Their reasons often matter more than their pick.
Turn preference into a number you can defend
The reason to do this at all is so you stop guessing. Hampton's approach gets you quantified feedback, like the percentage of users who preferred each option. That's the thing you bring back to the room. Not "I think," but "62 percent picked this one, and here's what they said about it."
In a second write-up, Hampton runs quick tests on shades and tints to see how small shifts change the feel and the brand fit. You don't need a huge study. A short test with real users beats a long argument with none. The point is you walk out with evidence, and evidence ends the debate.
Match the method to the color decision
Here's the split to keep in your head. If the color choice has a clear action behind it, A/B test it and watch behavior. If the choice is about feel or brand fit, run a preference test and count the votes without leading anyone. Same goal either way: a defensible answer.
On Monday, pick your loudest color argument and turn it into a test. Write down the two or three options and the one question you're really asking. Decide up front what number would settle it. Then go get that number instead of relitigating taste next week.
Three questions for your team
- For our next button or CTA, does higher contrast actually drive more clicks, and how will we set up the test to isolate that one change?
- On our brand color debates, are we showing options and letting users react, or are we asking questions that steer them toward the answer we already picked?
- What number would we accept as a winner before we run the test, so the result settles the argument instead of starting a new one?



