Visual elements

B2B SaaS products feature dozens of screens, tables, complex forms, role differences, and customization. Without documentation, each designer and developer interprets elements in their own way → the interface becomes fragmented → users encounter inconsistencies → the number of errors increases.

Below we explore which color groups you need, how to organize the architecture of shades, and why a well-designed palette is essential for designers, product leaders, and teams building design systems.

Documentation = a single source of truth that eliminates chaos and guarantees a stable UX.

A modern design system is not a library in Figma, but a process chain:
Figma → documentation → Storybook/code library → product.

Benefits for the project

• Time savings for the team
• Reduction of technical and UX debt
• Accelerated onboarding of new employees
• Consistency between Figma → code → product

Requirements and standards

Industry-specific

WCAG and EAA

Meeting WCAG and European Accessibility Act Requirements: Why It Matters Even for B2B Systems

WCAG is technically a recommended standard, and legislation such as the EAA or EN 301 549 references it with various exceptions. Because of this, it is easy to assume that accessibility applies only to products built for broad consumer use. In reality these requirements are far more relevant, and treating them lightly can become a critical mistake.

For many organizations, especially those purchasing enterprise software, WCAG AA compliance is mandatory. This is often not a corporate preference but a legal requirement within their region. In some cases, accessibility standards are written directly into SLAs. And if your product is used by public-sector institutions - education, healthcare, government or municipal services — compliance becomes effectively unavoidable whenever the system provides information or public-facing functionality.

Today WCAG has become a natural part of product maturity. Still, teams often wonder how to meet these requirements without compromising visual quality or user experience.

At first glance, building a polished, modern interface that fully complies with the guidelines seems difficult or even impossible. Yet the challenge usually lies not in the rules but in their interpretation. WCAG does not forbid design flexibility. It sets a foundation, leaving room for thoughtful, context-aware solutions. Variability is often the key.

A look at leading design systems shows this clearly: many of them use 10-pixel text. It is smaller than WCAG’s recommended minimum, yet it appears only in auxiliary places - secondary labels, subtle actions and microcopy users quickly memorize. WCAG’s minimum size applies to regular readable text meant for repeated, conscious consumption. Tiny button labels do not fall into this category, which means there is no formal violation.

What matters is providing alternatives. Users should have a way to access the same information at a larger size or in a different context. This can be done by duplicating the action in a context menu, offering a dedicated high-contrast or accessibility theme with larger minimum font sizes, or allowing users to switch between compact and spacious interface modes.

To an untrained eye, such workarounds may seem like bending the rules. In reality this approach aligns precisely with WCAG’s core purpose: ensuring access. The interface remains modern and visually coherent while still offering every user a path that meets accessibility expectations.

Technological

Internal

SLA

• Accessibility requirements - Compliance with WCAG 2.1 AA or EN 301 549. Guarantee that visual elements do not interfere with the use of assistive technologies.
• UI stability and visual integrity requirements - Continuity of visual patterns (do not make critical changes to the familiar interface without notification). Maintain UI backward compatibility - changes should not disrupt workflows.
• Control UI changes — notify about changes X days before release, develop and update documentation, provide training materials.
• Visual performance requirements — Maximum rendering time for screens or tables (with 50 fields and 100 rows). Formally, this is more of a technical issue. But loading speed is directly related to UX. And the organization and structure of components can also depend on the design. One solution is to use a local application — a shell that runs on the device and only displays the data it receives. The interface elements themselves are stored in it.
• Requirements for visual content - Quality and readability of graphs, charts, and metrics. Accessibility of visual reports (colors, labels, legends, tooltips). Correct display of exported PDF/Excel files.
• UI customization requirements - preservation of user settings, guarantee that custom UIs will not be disrupted by updates, levels of support for visual themes (branding, customer logos).
• Requirements for graphic elements and visual indicators - Clear definitions of color statuses, guarantee that color coding complies with standards, availability of text duplicates for color information.
• Requirements for visual changes and version control - Roadmap of UI changes. Backward compatibility of visual components.

However, this mechanical mapping does not always deliver the best result. Sometimes you need manual tuning to maintain balance and accessibility.

Foundations

Colors, palette, theme management

Typography

Grid, Layout, Spacing

Build a gradient from the lightest to the darkest shade, split it into equal segments, and take shades from the center of each segment. This ensures consistent optical steps across the palette.

2. Visible differences between neighboring shades

Shades must remain distinguishable even on screens covering up to 85% of the sRGB space, which is still common in enterprise environments. Find such a device and test the palette on it.

3. Contrast requirements

For text on colored backgrounds, follow WCAG:

• AA: contrast ratio 3.0 or higher
• AAA: 4.5 or higher

Check the contrast of this color against black (#000000) in the first half of the gradation and against white (#000000) in the second half. If your design specifies other base colors for text, it is better to use them for this check. Please note that the contrast check tool is already built into Figma. Also note that WCAG distinguishes between normal text and headings, with much higher requirements for the former.This becomes especially important for system statuses, alerts, and any color-dependent information.

A situation may arise where the shade does not meet the contrast requirements for either black or white, especially at the AAA level. In this case, it should only be used for filling elements that do not contain text or icons.

Because of these factors, separate color pairs for light and dark themes often work better than relying solely on automatic shade inversion.

This gives a total range from:

• 13 colors × 7–11 shades (≈91 shades)
• to 37 colors × 11 shades (≈407 shades)

A practical sweet spot for most B2B systems is 13 colors (12 colors plus one grayscale) × 9 shades, or 117 shades. Large enough to be useful, small enough to manage.

Real-World Examples From Existing Design Systems

Many teams worry that large palettes are hard to maintain. But leading enterprise systems prove the opposite:

• SAP Fiori: 100 shades
• Atlassian: 120
• Bitrix24: 189
• Oracle Alta UI: 284
• Oracle Cloud ERP: 441

Even a palette of 117 shades looks modest compared to these.

How to Work With the Palette

Below is a practical, Figma-friendly structure that scales well for enterprise design systems.

1. Wide Palette: The Foundation

This is the level where hue groups are defined. Keep the naming simple:

• Red
• Blue
• Yellow
• etc...

In Figma, create a Colors collection and a Wide palette section. Each color gets its own subgroup, each shade its own variable with HEX values.

Even if you are not planning multiple themes, you will almost certainly need at least a dark theme. Create an additional variable mode and define how each shade behaves when the theme switches.

Base Palette: Semantic Colors

Next comes the Base palette. These colors carry meaning in the interface.

Semantic names reflect the purpose:

• Primary
• Accent
• Success
• Warning

Grayscale can use numeric naming consistent with the wide palette.

Typical group sizes:

• Primary: 4–10 shades
• Accent: 5–10 shades
• Grayscale: 4–13 shades

Values in this layer reference Wide palette shades.

3. Context Palette: Colors for Component States

This level connects color semantics to real interface behavior. Here you define variables for:

• button states
• focus and hover states,
• borders and backgrounds,
input states, validation statuses, data states and alerts.

These variables should reference the Base palette. If the required shade is not available there, use the Wide palette.

This is the layer applied directly to components in Figma. It completes the hierarchy: shades → semantics → component behavior.

The result is a flexible and predictable color architecture that scales with your product.

Final Thoughts

A well-structured palette is more than a list of colors. It becomes an essential part of the design system’s architecture, supporting consistency, accessibility, and long-term product growth.

You can explore more about variable-based workflows in Figma’s documentation, but the model above gives everything you need to build a robust and scalable palette.