A color palette fails in practice almost never because the individual colors are ugly — it fails because there's no rule for how much of each color to use and what job each one has. Distribution and role discipline matter more than color choice; a mediocre palette used with clear rules outperforms a beautiful palette applied inconsistently.

The 60-30-10 distribution

Allocate roughly 60% of any given screen to a dominant neutral (background, surface color), 30% to a secondary color (supporting UI elements, secondary surfaces), and 10% to an accent color for emphasis — treat this as a starting ratio to adapt, not a rigid pixel count.
Audit an existing screen against this ratio when it feels visually chaotic — the most common cause is the accent color creeping past its 10% share because every element that "feels important" got the accent treatment, which then makes nothing stand out because everything does.
Let the dominant neutral do the visual heavy lifting; it should recede, not compete, so the smaller-share colors have something to stand out against.

One accent color, one job

Assign the accent color exactly one job — typically the primary call-to-action or the single most important interactive element on a given screen — and don't dilute it by also using it for decoration, illustration fills, or secondary buttons.
If a second emphasis color feels necessary, treat it as a second-tier accent used far more sparingly than the primary, not a peer to it — a palette with two equally weighted accents forces the eye to choose and creates competing focal points instead of one clear one.
Resist the temptation to use the accent color anywhere just because it's the brand's "favorite" color — its power comes specifically from its scarcity relative to everything else on screen.

Semantic colors stay reserved

Reserve error, warning, success, and info colors exclusively for those states — never repurpose "success green" as a decorative or branding color elsewhere in the interface, because doing so trains users to misread a decorative element as a status signal.
Choose semantic colors that are distinguishable from both the brand accent and from each other, including for color-blind users — red/green error/success pairs need a secondary cue (icon, shape) since red-green is the most common color-vision deficiency.
Keep semantic color meaning consistent across the entire product — if green means success on one screen, it can't mean "selected" or "premium tier" on another without breaking the signal the user has already learned.

Contrast ratios for text (WCAG)

Meet at least WCAG AA contrast: 4.5:1 for normal body text against its background, 3:1 for large text (roughly 18px+ bold or 24px+ regular) and for UI component boundaries/icons that carry meaning.
Check contrast for every text-on-background combination actually used in the product, not just the primary body-text case — a palette that passes for black-on-white body copy can still fail for a light-gray caption or accent-colored link text.
Treat contrast failures as palette bugs, not edge cases to patch later per-instance — if a color combination fails contrast in one place, it will fail everywhere else it's reused; fix it at the token level.

Light and dark variants

Design light and dark mode as two coherent palettes with matching semantic roles, not as one palette with colors mechanically inverted — a straight inversion frequently produces contrast failures and colors that read as jarring or neon in dark mode.
Reduce saturation and lighten pure accent colors somewhat for dark backgrounds — a fully saturated color that works on white often vibrates or causes eye strain against a dark surface.
Verify contrast ratios independently for both modes — a pairing that passes WCAG AA in light mode is not guaranteed to pass in dark mode and must be checked on its own.

Naming tokens by role, not hue

Name color tokens by their functional role (surface-primary, text-secondary, accent-interactive, border-error) rather than by their literal hue (blue-500, gray-200) at the point of use in components — role-based names survive a future palette or theme change without requiring every usage site to be found and edited.
Keep a second, lower-level layer of raw hue-based tokens (the actual hex values) that the role-based tokens reference — this is the standard two-tier token structure: primitives feeding semantic aliases, not primitives used directly in components.
When a rebrand or theme change happens, this structure means only the primitive-to-semantic mapping needs to update — component code referencing semantic names doesn't need to touch a single line.

Testing in context

Never approve a palette from isolated swatches alone — apply it to real screens (a dense data table, a form with validation states, a dark-mode settings page) before finalizing, since problems like insufficient contrast or accent overuse only surface in actual layouts.
Test the palette under the conditions real users will encounter it: on an actual display (not just a designer's calibrated monitor), in bright ambient light, and via a colorblindness simulator — a palette that only looks good in ideal viewing conditions isn't finished.

Color Palette Rules