SaaS Color System Generator - Build an Accessible Palette in Minutes

This document is the framework and methodology behind our SaaS Color System Generator. The interactive web tool lives at desisle.com/tools/color-system (when deployed).

This markdown guide teaches you:

• How to build an accessible color system from scratch
• How to generate WCAG-compliant palettes
• How to structure color tokens for SaaS products
• How to export to CSS variables, Figma tokens, and Tailwind config

Who this is for: Designers, developers, and founders building a new SaaS product who need a color system that looks professional AND passes accessibility standards.

Method 1: Start with your brand color

Step 1: Pick your brand color (the "500" value). This should be:

• Distinctive from competitors
• Appropriate for your product's tone (warm/cool, playful/serious)
• Legible at small sizes
• Works in both light and dark modes

Step 2: Generate 10 shades using HSL adjustments or a tool:

• Lighter shades (50-400): Increase lightness, slightly decrease saturation
• Base (500): Your starting color
• Darker shades (600-900): Decrease lightness, slightly increase saturation

Tools to generate palettes:

• Tailwind CSS Color Generator (uicolors.app)
• Radix Colors (radix-ui.com/colors)
• Coolors (coolors.co)
• Leonardo by Adobe (leonardocolor.io)

Method 2: Use perceptually uniform scales

Human perception of color isn't linear. HSL-based palettes can have uneven visual steps (some shades feel closer together than others).

Solution: Use perceptually uniform color spaces:

• OKLCH (newest, best results)
• LCH (similar, more widely supported)
• HSLuv (alternative)

Tools like Leonardo and Radix Colors use perceptually uniform scales by default.

Accessibility validation

Every color pair used for text + background must meet WCAG AA:

AAA (enhanced) requires:

Typical safe combinations:

• gray-900 text on white background: ~21:1 (excellent)
• primary-700 text on gray-50 background: ~9-12:1 (AAA)
• gray-500 text on white: ~4.6:1 (AA passing)
• primary-500 on white: usually 3.5-5:1 (depends on hue — test always)

Unsafe combinations (usually fail):

• gray-400 text on white: ~3:1 (fails AA for normal text)
• primary-300 on white background: rarely passes
• Yellow/amber text on white: almost always fails

Export to CSS Custom Properties

:root {
  /* Primitive tokens */
  --gray-50: #F9FAFB;
  --gray-100: #F3F4F6;
  --gray-900: #111827;
  --primary-500: #3B82F6;
  --primary-600: #2563EB;
  /* ... all other primitives */
  
  /* Semantic tokens */
  --color-bg-primary: var(--gray-0);
  --color-text-primary: var(--gray-900);
  --color-action-primary: var(--primary-600);
  /* ... */
}

/* Dark mode */
[data-theme="dark"] {
  --color-bg-primary: var(--gray-950);
  --color-text-primary: var(--gray-50);
  /* semantic tokens remap; primitives stay the same */
}

Export to Tailwind Config

// tailwind.config.js
module.exports = {
  theme: {
    extend: {
      colors: {
        gray: {
          50: '#F9FAFB',
          100: '#F3F4F6',
          // ... all shades
          950: '#030712',
        },
        primary: {
          50: '#EFF6FF',
          // ... all shades
          900: '#1E3A8A',
        },
        success: { /* ... */ },
        warning: { /* ... */ },
        error: { /* ... */ },
        info: { /* ... */ },
      },
    },
  },
};

Export to Figma Variables

In Figma:

1. Create a variable collection called "Color System"
2. Create modes: "Light" and "Dark"
3. Add primitives first (gray-50, gray-100, etc.) — same in both modes
4. Add semantics (color-bg-primary, etc.) — reference primitives, different values per mode
5. Use variables in component fills/strokes/text

1. Too many primary colors

One brand color is enough. Having "primary blue" AND "primary purple" AND "primary green" dilutes your brand identity.

2. Insufficient neutral shades

Many systems have 4-5 neutral shades and feel flat. You need 9-11 to build interface depth.

3. Wrong contrast in error messages

Light red (error-300) on white doesn't pass contrast. Error text should use error-600 or error-700.

4. Gray that's too cool or too warm

Pure neutral gray is boring but safe. Slight warmth (#F9F8F6) or coolness (#F9FAFB) is fine — but extreme warmth or coolness limits flexibility.

5. Not testing in dark mode

Light mode colors rarely translate directly to dark mode. Test every semantic combination in both modes.

6. Inconsistent saturation across shades

If primary-500 is vivid but primary-200 is dusty, the scale feels broken. Maintain consistent saturation (or predictable variation) across the scale.

7. Using color as the only signal

Color-blind users miss color-coded meaning. Always pair color with icon, label, or pattern.

8. Too-similar semantic colors

Success green and info blue should be visually distinct. Warning amber and error red should be clearly different (common failure: yellow-orange looks like red-orange).

• Web Content Accessibility Guidelines (WCAG) 2.1, W3C
• Material Design Color System (Google)
• Tailwind CSS Color Palette Documentation
• Radix Colors (workos.com/radix-colors)
• Refactoring UI book by Adam Wathan & Steve Schoger
• Understanding Color by Leatrice Eiseman
• Viktor Mukhachev, "HSL vs. OKLCH for Color Systems"

Created by Desisle — SaaS UI/UX Design Agency desisle.com | hello@desisle.com Free to use and share with attribution.

For a custom color system tailored to your brand, contact us at hello@desisle.com.