A UI palette is a set of roles
A UI color palette should support readable content, recognizable actions, clear feedback, and a coherent product identity. A collection of attractive swatches is only a starting point. The useful question is whether each color has a defined job and works with the surfaces and text around it.
TDP’s Color Theory & UI article introduces intentional color selection and visual balance. For product work, take that idea further by testing roles in a real screen. A fixed percentage such as 60:30:10 can be a composition exercise, but it is not a rule every dashboard or form must follow.
This walkthrough uses a settings screen as a working specimen. Include a primary action, secondary text, borders, and an error so the palette has to solve functional problems as well as express the brand.
Step 1. List the roles your interface needs
Start with a page background, a raised surface, primary text, secondary text, a border, and a primary action. Add success, warning, and error roles only where the interface needs them. This keeps the palette connected to behavior. A collection of attractive swatches does not yet explain how to design a form or dashboard.
Step 2. Choose a neutral foundation
Place real text and controls on the background before choosing accents. Check a paragraph, a table row, and a form field together. Warm and cool neutrals can both work; the useful question is whether the chosen combination supports the content and the brand. Avoid treating fixed color proportions as a requirement for every screen.
Step 3. Assign an accent and document its use
Use the accent for a deliberate role, such as the principal action. If it appears in every label, icon, and border, it stops distinguishing priorities. The starter palette below is an example to adapt. Its colors are not a blanket accessibility certification: validate each actual pairing and state.
:root {
--surface-page: #fcf5f1;
--surface-card: #ffffff;
--text-primary: #2e2e2e;
--text-secondary: #655c56;
--border-subtle: #dfd7d2;
--action-primary: #963b24;
--on-action: #ffffff;
}
Step 4. Check the combinations
Use the contrast checker on this page to inspect solid foreground/background pairs. WCAG’s text contrast criterion generally calls for at least 4.5:1 for ordinary text and 3:1 for large text, with specific exceptions. Large text is at least 18pt, or 14pt bold. Do not round a failing ratio up to a pass. See the linked W3C explanation for scope and exceptions.
Step 5. Apply the palette to a complete task
Build a default, hover, focus, error, and success example where those states exist. Identify whether an icon, label, or message also communicates each status. Review the result in the real layout, including disabled controls and dense content. Document permitted pairings rather than describing a color as universally “accessible.”
Worked example: a brand color that cannot do every job
Suppose a product has a bright orange brand color. It may work well in illustrations and highlights while requiring a different shade for an action with a white label. Instead of forcing the same value everywhere, preserve the brand family and define a role-specific action color after checking the pair.
Build the specimen with neutral surfaces first. Add the primary action, then feedback states. If everything competes for attention, reduce the number of emphasized roles before changing every hue. A clear hierarchy usually needs quieter supporting surfaces as well as a recognizable accent.
| Role | Question to answer | Example review |
|---|---|---|
| Page surface | Can content remain comfortable to scan? | Inspect a long settings page |
| Primary text | Is it readable on every intended surface? | Test body copy and labels |
| Secondary text | Is it quieter without disappearing? | Compare hints and metadata |
| Action | Can users identify the next step? | Inspect the main button among alternatives |
| Feedback | Is state understandable without hue alone? | Pair color with a label and explanation |
Build a scale around actual use
A scale gives you lighter and darker values for different surfaces and states. The number of steps is a design choice. Start with the roles you need, then add intermediate values when a real use case requires them. An evenly spaced numeric naming scheme does not guarantee evenly perceived differences.
Do not assume every hue needs the same number of production tokens. A brand family used throughout the product may need more range than a rare illustration accent. Keep the distinction between the available palette and the semantic roles consumers are allowed to use.
Check color in context, including themes
Measure the actual foreground and background pair. Transparent layers, gradients, imagery, and overlays can change what the user sees. Review hover, focus, selected, and error states where they are supported; a passing default state does not settle the rest.
Dark mode needs its own role mappings. Simply inverting the palette can change hierarchy and make accents overpower surrounding content. Compare the same screen and task in both themes, then record which values belong to each role.
Avoid universal claims about color meaning
Color associations depend on context, conventions, and the audience. A green button does not automatically communicate trust, and a red element does not explain the consequence of an action. Use language and structure to carry meaning, then let color reinforce it.
When choosing chart colors, test whether adjacent series remain distinguishable and whether labels or patterns provide another cue. A palette that works for actions may not work for data visualization. Keep those uses documented separately.
Deliver the palette as a usable specification
Provide role names, values, supported pairings, theme mappings, and examples. Include one screen showing ordinary content and one showing feedback or errors. Record exceptions and the reason for them so they do not become accidental defaults.
Continue with semantic color tokens to make the palette usable in code, and color contrast to verify its intended pairs. The color reference library provides exact starting values, not a substitute for choosing roles.
Completion checklist
- Every token has a named role.
- Text is tested on its actual surface.
- Actions and status are distinguishable without hue alone.
- Focus and error treatments remain visible.
- Light and dark modes are validated separately if supported.
Common questions
How many colors should a UI palette have?
Use enough roles to explain the product clearly. Add a new value when an existing token cannot serve the use case; a fixed count is less useful than a clear role map.
Can I use my brand color for small text?
Only if the resulting text/background pair meets your requirements. You may need a darker or lighter functional variant of the brand color.