How to Use Color Palettes in UI Design

Published September 1, 2026 · By the Shipirox team

A color palette can make a user interface feel clear, consistent, and recognizable—but only when each color has a job. In UI design, colors are not just decoration. They help people read content, understand hierarchy, recognize interactive controls, see status changes, and complete tasks. A well-structured palette makes a website or app easier to use across pages, screen sizes, and components.

The best UI palettes are usually smaller and more systematic than a moodboard. They include neutral surfaces, strong text colors, a primary brand hue, supporting colors, an action color, and semantic colors for success, warning, error, and information. This guide explains how to turn a group of colors into a practical UI system for websites, dashboards, apps, e-commerce stores, and digital products.

Start with semantic color roles

Instead of naming colors only by how they look, assign them to interface roles. A name like blue-500 is useful in a raw palette, but a name like color-action-primary explains why that color exists. Semantic roles make the system easier to understand, update, and share with designers and developers.

For example, the same green may be used as a brand color in one interface and a success color in another. Those are different meanings. Separating raw color values from semantic roles helps you avoid using one shade for unrelated messages just because it is available in the palette.

Build a neutral foundation first

Most interface pixels are neutral. Page backgrounds, cards, form fields, tables, modals, menus, dividers, and body text often make up more of the screen than the brand colors do. Start with a reliable neutral foundation before choosing strong accent hues.

Choose at least a light background, a slightly different surface color, a dark text color, a muted text color, and one or two borders. These values establish visual depth and make it easier to place colorful controls without creating a busy interface. Neutrals can be cool, warm, or slightly tinted to fit the brand, but they still need enough contrast for readable content.

Choose a primary UI color

The primary color represents the main brand or product action. It can be used for primary buttons, active tabs, selected controls, key links, progress indicators, navigation highlights, and focused product features. It should be distinctive enough to create recognition but stable enough to use repeatedly without overwhelming the interface.

Do not use the primary color for every element. If every icon, card, heading, border, button, and notification uses the same strong shade, the interface loses hierarchy. Let neutral surfaces carry most of the layout, then use the primary color where users need direction or where the product identity should be visible.

Create a scale for each main hue

A single HEX value is rarely enough for UI work. Components need hover, active, selected, disabled, background, and border states. Create light and dark steps around each core hue so you can choose values with a consistent relationship.

:root {
  --blue-50: #EEF5FF;
  --blue-100: #D8E8FF;
  --blue-200: #B5D0FF;
  --blue-500: #316DCE;
  --blue-600: #245AB3;
  --blue-700: #19468C;
  --blue-900: #10284F;
}

Use lighter values for selected-row backgrounds, information panels, soft tags, and subtle hover surfaces. Use a mid-tone for primary buttons, links, and active navigation. Use a darker tone for pressed states, high-contrast text, and emphasis. A scale keeps components related even when they need different visual weights.

Use an accent with restraint

An accent color is useful when you want to highlight a small number of elements. It can support an upgrade offer, a featured plan, a new feature label, a promotional badge, or a primary action that needs extra separation from the brand color. The accent should not replace the primary action color on every screen.

For example, an app may use blue for its normal primary buttons and amber only for an “Upgrade plan” card. A commerce site may use its brand green for navigation and coral only for “Add to cart.” Keeping the accent limited makes it easier for people to understand what deserves their attention.

Design component states deliberately

Interactive UI components need more than a default color. Buttons, links, inputs, tabs, checkboxes, menus, and cards should show what happens when a person hovers, focuses with a keyboard, presses, selects, disables, or encounters an error. Use a consistent state pattern so people can predict how the interface behaves.

A hover state should feel related to the default state, not like a new palette. A focus state should be visible even if the user does not use a mouse. A disabled state should communicate that the control is unavailable, but important text still needs enough contrast to be understood.

Use semantic status colors carefully

Success, warning, error, and informational states help users understand feedback. Green is often used for success, yellow or amber for warning, red for error, and blue for information. However, the exact colors should fit your palette and should be supported by text, icons, and placement.

Never rely on color alone to communicate a status. A form field should not show only a red border; it should also include a clear message explaining what needs to change. A success message should include confirmation text. A warning should describe the potential consequence and any available next step.

:root {
  --success-bg: #E8F5EC;
  --success-text: #1F6B3A;
  --warning-bg: #FFF4D8;
  --warning-text: #805800;
  --error-bg: #FDEBEC;
  --error-text: #A12C36;
  --info-bg: #EAF2FF;
  --info-text: #245AB3;
}

Use color for hierarchy, not decoration

Color should help people scan the interface. Use dark text for the most important content, muted text for secondary information, a primary color for actions and active states, and a limited accent for focused attention. When every card has a bright fill and every heading uses a different hue, the interface becomes harder to scan.

The 60-30-10 rule can help you think about balance. Use neutral backgrounds and surfaces for most of the interface, apply your primary and supporting hues to a smaller share, and reserve the strongest accent for the smallest share. The exact percentages are flexible, but the rule encourages visual hierarchy.

Check contrast and accessibility

Accessible contrast is essential in UI design because people need to read labels, understand controls, complete forms, and interpret feedback. A palette that looks polished in a swatch board can fail when colors are applied to small text, thin icons, buttons, field outlines, or charts.

For normal body text, a contrast ratio of at least 4.5:1 is a common WCAG AA target. Large text can use 3:1. Also test non-text elements such as focus indicators, input boundaries, selected states, and essential icons. Check your real screens, not only the palette file. Read our color contrast and accessibility guide for more detail.

Avoid using red and green as the only way to distinguish positive and negative states. Add labels, icons, shape differences, position, or patterns. These additions help users who have color-vision differences, view the interface in bright conditions, or scan content quickly.

Support light and dark modes

Light and dark themes should use semantic roles, not simply invert every raw color. A light background in one mode may become a dark surface in another, while text and border colors need to change to keep the same readable relationship. The purpose of a token stays the same even when its underlying value changes.

:root {
  --color-bg: #F7F8FA;
  --color-surface: #FFFFFF;
  --color-text: #1C2430;
  --color-text-muted: #667085;
  --color-border: #D7DCE3;
  --color-action: #316DCE;
}

[data-theme="dark"] {
  --color-bg: #121820;
  --color-surface: #1A222D;
  --color-text: #F4F7FB;
  --color-text-muted: #B7C1CE;
  --color-border: #344050;
  --color-action: #7EAEFF;
}

Test both themes separately. A color that works well as a button in light mode may need a different brightness in dark mode. Images, shadows, charts, disabled states, focus rings, and status messages may also need adjustments.

Use design tokens for consistency

Design tokens store the decisions behind your UI palette in reusable names. They help designers and developers work from the same system and make global updates easier. Instead of setting a button background to a raw value everywhere, define it once as an action token.

:root {
  --color-bg: #F7F8FA;
  --color-surface: #FFFFFF;
  --color-text-primary: #1C2430;
  --color-text-secondary: #667085;
  --color-border-default: #D7DCE3;
  --color-action-primary: #316DCE;
  --color-action-primary-hover: #245AB3;
  --color-focus-ring: #7EAEFF;
  --color-status-error: #A12C36;
}

Use the same token names in your design library, component documentation, and CSS or application code. If you later change the brand blue, improve contrast, or add dark mode support, the semantic system makes the update faster and safer.

Apply the palette to common UI parts

Common UI palette mistakes

• Using raw color names instead of roles. Semantic names explain where colors belong and make future updates easier.
• Starting with bright brand colors before neutrals. Interfaces need backgrounds, surfaces, text, borders, and muted information before accent colors.
• Using one value for every state. Buttons, inputs, links, and controls need hover, focus, pressed, selected, disabled, and error behavior.
• Hiding focus indicators. Keyboard users need a visible, high-contrast focus state to navigate the interface.
• Relying on color alone. Pair errors, warnings, selections, and status states with text, icons, or other visual signals.
• Skipping contrast checks. Test real text, controls, borders, charts, and feedback states instead of trusting a swatch board.
• Applying dark mode by inversion. Define semantic tokens and test each relationship in both light and dark themes.

Build a UI palette system

Using color palettes in UI design is about making decisions repeatable. Start with neutral backgrounds, surfaces, text, and borders. Add a primary action color, create light and dark steps for interactive states, choose a limited accent, and define semantic colors for feedback.

Then test the palette inside real components and screens. Check contrast, show focus clearly, avoid using color as the only signal, and document the final tokens in your design library and code. A role-based palette makes every page and component feel more coherent while helping users understand and complete tasks with less effort.