A business colour palette is an operating system, not a list of emotions. It must direct attention, separate levels of content, communicate states and remain legible across devices. This guide builds colour around roles, contrast and real interfaces.
Start with jobs, not colour-psychology lists
Blue does not automatically make a company trustworthy, and red does not guarantee energy. Meaning depends on culture, market, copy, imagery and context. Define what users must distinguish: background, text, links, primary and secondary actions, success, warning and error.
A signature brand colour can build recognition without serving every interface role. If it fails contrast for text or controls, add a darker or lighter functional shade rather than forcing brand recognition and usability into conflict.
Build a small palette and name colours by role
A practical foundation usually contains neutral surfaces and text, one recognisable brand colour, an action colour and necessary feedback colours. The 60–30–10 idea can help sketch a composition, but it is not a web requirement and cannot create hierarchy by itself.
Document semantic roles such as text-primary, surface-accent and action-primary instead of relying only on names such as blue-500. Roles make a palette easier to change and reduce one-off colours.
- backgrounds and surface levels
- primary and secondary text
- links, buttons and visible focus
- success, warning and error
- borders, icons and data-visualisation colours
Measure contrast for every real pair
At WCAG 2.2 level AA, normal text needs a contrast ratio of at least 4.5:1 against its background; large text needs 3:1. Essential interface components and state indicators need at least 3:1 against adjacent colours. These are thresholds, not a target for making the interface as faint as possible.
Test every combination in use: text against its surface, button text against the button and controls or focus indicators against neighbouring colours. Logotypes are exempt from the text-contrast criterion, but the same colour receives no exemption when reused in an interface.
| Element | WCAG 2.2 AA minimum | Check |
|---|---|---|
| Normal text | 4.5:1 | Every text and background pair in each state |
| Large text | 3:1 | Size and weight meet the definition of large text |
| Essential UI components | 3:1 | Boundaries, icons, selection and focus remain visible |
| Logotype | No minimum | The exception does not cover other text or UI |
Colour must not carry meaning alone
A red border does not explain what is wrong with a field. Add a text error and, where useful, an icon or shape. Apply the same principle to charts, selected tabs, availability and success states.
Distinguish links in body copy with more than hue, for example an underline. Hover does not help on touchscreens or for keyboard users, so default and focus states must also be clear.
Test complete views and every state
A palette sheet cannot reveal how colours behave in a real page. Test a home page, form, card or table view, and error and success messages. Review light and dark themes separately when both exist.
Automated contrast tools find numerical failures but cannot judge hierarchy, comprehension or whether meaning survives without colour. Also inspect zoomed views, greyscale, keyboard focus and realistic content.
- default, hover, active, focus and disabled states
- long headings and realistic error messages
- text over images and gradients
- bright and reflective mobile conditions
Document the palette as a maintained system
Record approved values, semantic roles, contrast pairs and prohibited combinations in one place. Implement the same roles as design tokens or CSS variables so colour decisions do not scatter across components.
Review the system when new components, themes or channels appear. A strong colour system is not a large library of shades but a small set of decisions that supports consistent new work.
Digitari helps companies build recognizable and practical visual systems. Explore graphic design.
Sources and further reading
Contrast and use-of-colour figures are based on W3C's WCAG 2.2 guidance. The design rules are practical starting points, not universal requirements.
