How to Design a Color System for a SaaS Product
A color palette and a color system are not the same thing. A palette is a collection of colors. A system is a set of rules, relationships, and documented decisions that determine how those colors are used consistently across every state, component, theme, and screen in a product. For a single landing page, a palette is sufficient. For a SaaS product used daily by thousands of people across desktop, mobile, and potentially multiple themes, a system is the minimum viable approach.
Building that system is one of the highest-leverage design investments a product team can make. Done well, it eliminates entire categories of design decisions at the component level, accelerates development velocity, and produces a more consistent, trustworthy product experience. Here is how to build it.
Layer 1 — Primitive Tokens (The Raw Colors)
Every color system starts with a set of primitive tokens — the raw color values that form the complete range of colors available in the system. These are not assigned to any specific purpose yet. They are simply the palette: every hue, tint, shade, and neutral available to the system.
A well-structured primitive layer typically includes a complete scale for each brand color (10 steps from lightest to darkest), a complete neutral scale (10 steps from near-white to near-black), and a set of semantic base colors (red, green, amber, blue) at multiple lightness levels for use in status states. Each primitive token is named for what it is, not what it does: blue-500, green-200, neutral-900.
The process of building these scales — generating the full tint-to-shade range for each hue with appropriate saturation variation — is covered in our Ultimate Guide to Building a Color Palette from Scratch. The primitive layer of your color system is the output of that process, documented in your design token file.
Layer 2 — Semantic Tokens (The Named Roles)
Semantic tokens reference primitive tokens and assign them to specific functional roles. This is the layer where meaning is assigned. Instead of a component referencing blue-500 directly, it references color-action-primary, which maps to blue-500 in the light theme and blue-300 in the dark theme.
A complete semantic token set covers backgrounds (page, surface, overlay, sunken), borders (default, strong, focus), text (primary, secondary, placeholder, disabled, inverse, on-color), and interactive states (action primary, action secondary, danger, success, warning, info) — each with their own default, hover, active, and disabled variants.
The power of this layer is theme switching. When a user activates dark mode, only the semantic token mappings change — every primitive referenced by a semantic token is remapped to its dark-mode equivalent. Every component automatically inherits the correct colors without a single component-level code change. For teams managing multiple themes, this is not a luxury — it is the only scalable architecture. The mechanics of this theme system are covered in our article on Dark Mode Color Palettes: How to Design for Both Themes.
Layer 3 — Component Tokens (The Specific Overrides)
Some components have color needs specific enough to warrant their own token layer. A data table's alternating row colors, a sidebar navigation's active state, a tooltip's background — these may need values that are not part of the standard semantic set but should still reference primitives rather than raw hex codes. Component tokens provide this specificity while maintaining the system's integrity.
Not every component needs component tokens — use this layer sparingly, only for genuinely unique needs. Over-engineering the component token layer produces a system that is nominally consistent but practically impossible to maintain.
Semantic Color Categories Every SaaS Product Needs
Beyond the brand colors, every SaaS product requires a complete set of semantic status colors that communicate system states clearly. These categories are standard enough that users bring expectations to them from other software they use.
Danger / Error (Red-family): Destructive actions, validation failures, system errors. Never use this color decoratively. If red appears anywhere in your interface that is not communicating danger, error, or a required action, you are training users to ignore the semantic meaning.
Warning / Caution (Amber-family): Non-critical alerts, approaching limits, advisory states. Amber should appear when something needs attention but not immediate action.
Success / Confirmation (Green-family): Completed actions, positive states, passing validations. The green that appears in a success toast should be the same green in every success state across the entire product.
Informational (Blue-family): Neutral announcements, tooltips, documentation links. Often the brand blue, or a lighter variant of it, depending on the primary brand color.
Each of these categories needs values for both themes and for text use, background use, and border use — a minimum of six values per category (light background, default, dark text in light theme; light text, default, dark surface in dark theme). Running all of these through contrast verification is mandatory. Our testing guide at How to Test Color Contrast Ratios Before Launching Your Site provides the full workflow.
Documentation — The Part That Makes It a System
A color system without documentation is a collection of files. The documentation is what makes it a system — a shared agreement about what the colors mean and how they should be used.
Every semantic token should be documented with: the token name, the primitive it references in each theme, the specific use case it is intended for, and examples of correct and incorrect usage. The incorrect usage examples are as important as the correct ones — showing designers and developers where they might be tempted to misuse a token prevents the drift that gradually undermines system consistency.
Publish this documentation where every member of the product team can access it — in your design system Figma file, in your engineering wiki, in your onboarding materials. A color system that lives only in the lead designer's head is a color system that will not survive the first team expansion.
Auditing and Evolving the System
Color systems are not static. Products evolve, new component types emerge, themes expand, brand guidelines update. Build quarterly color system audits into your design process — review the token usage across the product, identify places where components are referencing primitives directly instead of semantic tokens, and look for semantic token needs that the current system does not cover.
Evolution is healthy. Drift is not. The distinction is whether changes are deliberate and documented, or whether they are ad hoc decisions that accumulate into inconsistency. A color system maintained with discipline over years becomes one of a product's most valuable design assets — the invisible infrastructure that makes everything look and feel like it belongs together.