Requirements and standards

In B2B SaaS products, design is not a one-time activity but an ongoing, distributed process. Interfaces evolve continuously, teams grow, responsibilities shift, and new features are delivered in parallel. Without clearly defined standards and requirements, design decisions quickly become fragmented, leading to inconsistencies that increase cognitive load for users and slow down product development.

Documented standards and requirements within a design system create a shared foundation for all teams involved. They define not only *what* should be built, but *how* and *why* it should behave in a certain way. This clarity reduces ambiguity, minimizes subjective interpretation, and ensures that design decisions remain consistent across products, platforms, and time.

For B2B SaaS solutions—where reliability, predictability, and long-term usability are critical—these standards act as a stabilizing layer. They help scale design quality alongside the product, support efficient collaboration between design and development, and ultimately protect the user experience as the system grows in complexity.

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.