TasteMaker Build your brand kit

Choosing brand colors: a method that survives contact

Updated 2026-07-08 ยท 5 min read

Most brand color advice starts with psychology. Blue means trust, red means urgency, green means growth. This is not wrong so much as unhelpful, because every company in a category reads the same article and ends up the same blue.

A more useful starting question is not "what does this color mean" but "what is this color for."

Assign roles before you pick hues

A palette is not a set of colors you like. It is a set of jobs, each of which needs a color. Write the jobs first:

Now you have seven or eight slots. Notice how few of them are "brand" colors. In a typical interface, the brand hue appears on the primary action, occasionally an accent, and nowhere else. The other 95% of the screen is grays.

A brand palette is mostly a gray ramp with one opinion in it. Companies that get this ship coherent products. Companies that pick five vivid brand colors ship products where every screen is a fight.

Stripe's public guidance names exactly two: slate and blurple. Notion's system is functionally monochrome. That restraint is the choice, not a lack of one.

Pick the one opinion

For the single hue that carries the brand, three practical constraints beat any color-psychology chart.

It must not be your competitor's. Open five competitors, screenshot their primary buttons, and put them side by side. If you land in that cluster you have chosen invisibility. This takes ten minutes and skips a month of debate.

It must work as a button. A hue that is beautiful in a hero gradient and illegible as a 40px button with white text on it has failed at its only job. Test it as a button first, in the smallest place it will appear.

It must have room above and below. You need a hover state (darker) and a subtle background tint (much lighter) of the same hue. A color already at maximum saturation and mid lightness has nowhere to go. Pick from the middle of a ramp, not the end.

The contrast math that decides it

Here is where most palettes die, and it is arithmetic, not taste.

WCAG 2.2 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (roughly 18pt, or 14pt bold) and for the boundaries of interactive components. Contrast ratio runs from 1:1 (identical) to 21:1 (pure black on pure white).

Two consequences fall out immediately.

First, your primary action color must clear 4.5:1 against whichever text color sits on it. White text on a mid-tone brand color usually lands between 3:1 and 4.5:1, which is the most common accessibility failure in a real product. Check this before you fall in love. If white fails, either darken the color or use a dark text on it, and if dark text on it looks wrong, the color is wrong.

Second, pure black text on pure white is 21:1, which is more contrast than you want. It reads as harsh and it vibrates on screens. Most careful systems land text somewhere around a very dark desaturated blue or gray on a slightly warm off-white. Notion does exactly this: the background is not #FFFFFF, which is why quoting it as such is inaccurate.

Stripe wrote up how it built an accessible color system, and the useful takeaway is structural: they generate ramps and check contrast as a property of the system. Contrast is a constraint on generation, not an audit you fail later.

Build a ramp, not a swatch

For each hue you keep, generate a ramp of nine to eleven steps from very light to very dark. Then assign roles to steps, not to standalone colors:

brand-50    background tint
brand-100   subtle fill
brand-500   primary action        <- the "brand color"
brand-600   primary action hover
brand-700   primary action active
brand-900   text on light tint

Do the same for gray. Now dark mode is not a redesign, it is a remapping: surface points at gray-50 in light and gray-900 in dark, and every component that asked for surface follows. That mechanic is what design tokens exist to express, and it is why the ramp matters more than the individual hex.

A caution on generating ramps by mechanically adjusting lightness in HSL: it produces steps that are perceptually uneven, and yellows and blues at the same "lightness" will look nothing alike. Perceptual color spaces (OKLCH, LCH) fix this, and every modern browser supports oklch() in CSS. If you are building a ramp by hand in 2026, build it in OKLCH.

Test it in the three places that matter

Before you commit, put the palette through three checks. Each one has killed a palette that looked perfect in a swatch grid.

  1. A dense screen. A table, a form, and a nav, all at once. Colors that sing in isolation fight when there are forty of them on screen.
  2. Grayscale. Desaturate the whole interface. If the primary button stops being obvious, your hierarchy was carried by hue alone, and roughly 4% of men will not see it the way you do.
  3. A dark background. Even if you never ship dark mode, this reveals whether your colors are defined by their hue or by their contrast against white. Colors that only work on white are not a system.

What to do with the psychology

Use it last, as a tiebreaker.

Once you have three candidate hues that all pass contrast, all avoid the competitor cluster, and all survive a dense screen, then it is reasonable to ask which one feels right for the category. At that point you are choosing between three defensible options rather than starting from a vibe and reverse-engineering the constraints. The constraints have already done the work.

Next

Or, if you would rather choose by looking than by reasoning: TasteMaker shows you pairs, learns what you pick, and hands back a full ramp with contrast already checked.

Sources

Keep reading

TasteMaker turns your design taste into a brand kit AI coding tools read directly: design tokens, an Agent Skill package, and a live MCP server. Free to build.

Build your brand kit