Skip to content
Web Design Guide
Search intent: color palette for app UI design

Color Palette for Apps: Building a System That Scales

App color systems are more complex than brand color palettes. An app needs colors for every state, every component, and both light and dark modes — from a starting point of three or four brand colors. Here is how to architect that expansion correctly.

UI/UXApp DesignDesign SystemsWeb Design
Key points
A brand palette has 3-5 colors. A functional app color system needs 30-50 distinct values: interactive states, semantic feedback colors, elevation layers, and text role variants. These are not the same thing — the brand palette is the input, and the app color system is the engineered output.
Color roles matter more than color values. Before assigning any hex code, define the roles your palette needs to fill: primary action, secondary action, surface, elevated surface, destructive action, success state, warning state, disabled state. Then find colors that fill those roles with sufficient contrast.
Semantic tokens — color values named by role rather than appearance — are the foundation of maintainable app color systems. 'button-primary-background' is more useful than 'blue-500' because it communicates intent, survives rebrands, and enables theme switching without component-level changes.

The gap between brand palette and app color system

Brand guidelines typically define 3-5 colors: a primary brand color, a secondary accent, and a set of neutral tones. An app needs many more. You need feedback colors (error red, success green, warning amber, info blue) that may not appear in the brand palette at all. You need an elevation system: multiple surface levels for cards, modals, and panels that must all be distinguishable without introducing new hues. You need interactive state colors: hover, active, focus, and disabled variants for every interactive component. You need dark mode variants of all of the above. Bridging the gap from 5 brand colors to a complete system means systematically deriving the required values from the brand palette's hue and saturation structure, not choosing arbitrary new colors.

Designing for interactive states

Every interactive element needs at minimum four states: default, hover, active (pressed), and disabled. The standard approach is to derive hover and active states by adjusting the lightness of the default value — hover typically lightens or darkens by 8-12%, active by 15-20% in the same direction. Disabled states are typically the default value at 40-50% opacity, or a flat gray that removes the hue information entirely to signal non-interactivity. These derivations should be systematic: if your primary button default is L:45%, the hover is L:38%, and the active is L:30%. Consistent derivation logic means the interactive states will feel coherent across components, even when the underlying default colors differ.

Semantic tokens and long-term maintainability

Semantic color tokens are the most important architectural decision in an app color system. A token named 'primary-action-background' can reference a blue value today and an orange value after a rebrand — every component using that token updates automatically. A token named 'blue-500' is tied to that specific hue forever and must be manually replaced everywhere when the brand changes. Beyond rebranding, semantic tokens enable theme switching: light and dark mode are implemented as two sets of primitive color values bound to the same semantic token names. The component code never changes — only the values behind the tokens differ per theme. The Dark Mode UI Kit exports a complete semantic token structure in this format, with CSS custom property exports for web and Figma token exports for design tool use.

Practical next step

Move from the guide into a concrete palette lane

Guides explain the use case. Collections prove the taste. Packs handle the export and implementation layer.

Related guides