How Do Designers Pick Colours — Tools and Techniques That Work
Colour picking is less about staring at a wheel and more about making a decision that survives real UI: contrast, states, branding, and different screens. If you need to move from vague taste to a palette you can ship, try our free color picker and start testing values instead of guessing.
Start with the job, not the hue
The best palettes usually come from a brief, even a tiny one. Ask what each colour has to do: identify a brand, signal success or danger, separate surfaces, or keep a dashboard calm enough that people can read it for eight hours straight.
That changes the whole process. A finance app, a docs site, and a game launcher can all use blue, but they should not use it the same way. One may need high contrast and sober neutrals; another may need a vivid accent and more generous spacing between coloured elements.
Before you touch the picker, write the roles down:
- Primary: the main brand or action colour.
- Accent: the colour that pulls attention without taking over.
- Surface: backgrounds, cards, panels, and inputs.
- Text: foreground colours that must remain readable.
- Status: success, warning, error, info.
That list keeps colour picking from turning into random slider archaeology.
Build a palette in layers
Most people start with the accent and then wonder why the rest feels off. It is usually better to start with neutrals, then slot in a single anchor colour, then add support colours only if the interface actually needs them. The interface gets its structure from the neutral ramp; the accent is just the spice.
A simple workflow looks like this:
- Choose a neutral background and a readable text colour.
- Pick one anchor colour for the main brand or action.
- Derive hover, active, and disabled states from that colour family.
- Add semantic colours for alerts only if the UI needs them.
- Check contrast on every text-on-surface combination.
This is where tools that convert between formats help. If you are moving between design tokens, CSS variables, and hand-tuned UI values, our guide to hex and RGB colour values is a handy reference for what those strings actually mean in code.
For example, if your brand colour is #4F46E5, do not just drop it everywhere. Test it on white, near-black, and muted surfaces, then generate lighter and darker versions for hover and focus states so the UI still reads as the same system.
Use contrast like a sanity check
Colour that looks good in isolation can fail the minute text lands on top of it. Contrast is the hard part because your eye adapts quickly, and a colour that feels “fine” on a bright monitor can be miserable on a phone in dim light.
For text, the rule is simple: if people have to squint, you already lost the battle. A soft pastel button with white text may look polished in a mockup and fall apart in production. Likewise, grey-on-grey dashboards often look subtle right up until a user tries to read them.
Test the actual combinations you plan to ship, not abstract swatches. Try regular text, small labels, placeholder text, icons, borders, and disabled states. Borders matter more than people expect, especially when they sit on similar surfaces and become invisible.
If you need a quick confidence check, pair colour picking with contrast testing and compare several values side by side. The point is not to chase perfect aesthetics in a vacuum. It is to make sure the thing remains legible when real content lands in it.
Good colour systems do not just look consistent. They behave consistently under pressure.
Make the UI look real before you judge the colours
Designs are easiest to misread when the content is fake in the wrong way. A card with a single line of lorem ipsum will never stress a layout the way actual names, dates, and mixed-length labels will. Colour issues often hide in those details, because spacing and line breaks change the visual weight of every surface.
Use realistic placeholder data while you test. A profile card with a long name, a short name, a phone number, and a date field gives you a better read than a page full of identical dummy text. For quick test data, tools like random data can save you from hand-building fake records one by one.
That matters most in tables, dashboards, and forms. A pale row stripe that looks clean with three columns can vanish when a date column wraps, and a warning badge that looks strong in isolation can get swallowed once the row is packed with actual content.
In practice, try rendering something like this while you judge your colours:
<div class="user-card">
<h3>Mina Patel</h3>
<p>mina.patel@example.dev</p>
<p>Joined: 2026-07-08</p>
<button class="primary">Invite to project</button>
</div>
.user-card {
background: var(--surface-1);
color: var(--text-primary);
border: 1px solid var(--border-subtle);
}
.primary {
background: var(--brand-500);
color: #fff;
}That small amount of realism tells you whether the palette works or just photographs well.
Choose tools that compare, not just collect
A decent colour workflow is less about finding one magical picker and more about comparing values fast. You want to move from one colour to a family of related colours without opening six tabs and forgetting which one had the better contrast ratio.
That is why a picker, a mixer, and a contrast check often travel together. Pick a colour, nudge it lighter or darker, inspect the resulting value, and then compare it against your intended background. Repeating that loop is faster than trying to eyeball harmony from the wheel alone.
When you need to go deeper, the useful question is not “what colour is this?” but “what does this colour do in the system?” If you can answer that, the rest is mechanical: convert, compare, adjust, repeat.
One practical trick is to treat colour values like code. Keep them in tokens or variables, for example:
:root {
--brand-500: #4F46E5;
--brand-600: #4338CA;
--surface-0: #ffffff;
--surface-1: #f8fafc;
--text-primary: #0f172a;
--text-muted: #475569;
}Then colour picking becomes editing a system, not repainting a page one pixel at a time.
Don’t ignore context: screens, themes, and states
Colours do not live in a vacuum. A palette that looks crisp on a retina display may feel too thin on a washed-out laptop screen, and a dark theme can make saturated colours bloom harder than expected.
Check your palette in more than one environment. Light mode, dark mode, disabled states, hover states, and focus rings all change how the colours behave. If you only evaluate the “default” version, you are only testing the easiest case.
Accessibility is part of the same job. Keyboard focus, error messages, and selected states should not depend on colour alone. Add shape, weight, icons, or borders where it helps, because users should not need perfect colour vision to understand the interface.
If your palette needs to support multiple themes, define tokens by role instead of by literal colour name. --surface-warning is more useful than --yellow-300 if the same semantic slot needs to become amber in light mode and a different hue in dark mode.
Real-World Example
Say you are building a small admin panel for subscription billing. The product team wants it to feel calm, technical, and trustworthy, with a single strong action button and clear alert states. The first draft uses a bright teal for everything, because the colour looked “clean” in the picker.
That usually ends badly. Teal buttons, teal links, teal badges, teal borders, and teal highlights all blur into one noisy layer. The fix is to assign roles and narrow the palette until each part has a job.
Here is a basic before/after transformation:
Before
- Background: #E6FFFB
- Text: #38B2AC
- Button: #38B2AC
- Links: #38B2AC
- Warnings: #38B2AC
After
- Surface: #F8FAFC
- Text: #0F172A
- Border: #CBD5E1
- Primary button: #0F766E
- Link: #2563EB
- Success: #16A34A
- Warning: #D97706
- Error: #DC2626The second version works because each colour has a distinct purpose. The primary action is still on-brand, but links and alerts no longer compete with it. The interface ends up calmer because the palette stopped trying to do every job at once.
If you wanted to implement that in CSS, the token split might look like this:
:root {
--surface: #f8fafc;
--surface-elevated: #ffffff;
--text: #0f172a;
--text-secondary: #475569;
--border: #cbd5e1;
--primary: #0f766e;
--link: #2563eb;
--success: #16a34a;
--warning: #d97706;
--danger: #dc2626;
}That is the actual payoff of good colour picking: less guesswork later, fewer hard-to-read states, and a palette that survives real content.
Frequently Asked Questions
How do designers choose a colour palette?
They usually start with the project’s role, not with random swatches. Brand colour, surface colour, text colour, and semantic states come first, then everything else gets shaped around those decisions.
What is the easiest way to check colour contrast?
Use a contrast tool and test the exact text and background pair you plan to ship. Do not rely on how the colours look in isolation, because bright screens and small text can make a “nice” palette unreadable.
Should I pick colours in HSL, RGB, or hex?
Use whichever format matches your workflow. Hex is compact for design tokens, RGB is direct for CSS and debugging, and HSL is often easier when you want to make a colour lighter or darker without changing its personality too much.
How many colours should a UI palette have?
Usually fewer than people think. A solid UI often needs a small set of neutrals plus one primary accent and a few semantic colours for success, warning, and error.
Before You Go
Colour picking gets a lot easier when you treat colour as a system instead of a taste contest. Start with the job, assign roles, test contrast early, and judge the palette against real content rather than blank mockups.
If you want a quick browser-based way to compare values and tighten up a palette, give the color picker a spin. Pair it with real data, a few token variables, and one brutally honest contrast check, and you will usually land on something that actually works.