UX Overhaul & Design System for a B2B SaaS Product

The situation

B2B SaaS products tend to grow one feature at a time. After a few years there are several table styles, three kinds of modal and a settings area that nobody wants to touch. New customers need long onboarding calls, support tickets point to the same confusing screens, and enterprise buyers send accessibility questionnaires the team cannot answer. Designers keep a Figma file that no longer matches production, and engineers rebuild the same button in every new module.

Our approach

1. Start with research, not pixels

We interview customers across roles, review support tickets and analytics, and run moderated usability tests on the workflows that matter most, such as setting up an account, building a report or approving a request. The goal is a short, ranked list of problems backed by evidence, so redesign effort goes where users actually struggle.

2. Audit the product as it is

Our designers run a heuristic UX audit and an inventory of every UI pattern in production: buttons, inputs, tables, filters, empty states and error messages. An accessibility specialist tests key flows with keyboard navigation and screen readers against WCAG 2.2 AA, including focus visibility, target size and accessible authentication. The inventory usually shows that a few dozen components cover most screens, which sets the scope of the system.

3. Define tokens once and sync them to code

We build the Figma library on a token foundation: color, typography, spacing, radius, elevation and motion, with semantic names like surface-muted or text-danger rather than raw values. Tokens Studio stores them as JSON in the same Git repository as the code. Style Dictionary compiles them into CSS custom properties and TypeScript constants, so a change approved in Figma reaches code through a normal pull request. Light and dark themes, and brand themes for white-label customers, come from the same source.

4. Build a component library engineers want to use

Components are written in React and TypeScript on top of accessible primitives such as Radix UI, so keyboard handling and ARIA behavior are correct by default. Each component ships with Storybook documentation, usage guidance and interactive examples. Chromatic catches visual regressions, and axe-core and Playwright tests run on every pull request. The library is versioned with Changesets and published to a private npm registry, with clear release notes and migration guides.

5. Redesign the key workflows on the new system

With the foundation in place, we redesign the workflows ranked highest by research, prototype them in Figma and validate them with users before engineering starts. Those screens become the first production consumers of the library and prove it works under real conditions. We track task completion and support ticket themes before and after each release, so the team can see whether the changes are helping and adjust the next round of work. Findings that point to missing components or unclear guidance feed back into the system itself.

How we deliver it

We roll out in phases so feature work never stops. New features are built system-first, existing screens migrate module by module, and a compatibility layer lets old and new styles live side by side during the transition. We set up a small contribution process so product teams can propose new components instead of building one-off versions. Lint rules flag hard-coded colors and deprecated components, and a simple adoption report shows how much of each app runs on the system, which helps teams plan the remaining migration. Our web and mobile app development engineers work alongside your team so the system is owned internally when we step back.

Is this relevant to you?

If your product feels inconsistent, design and code have drifted apart, or accessibility questions are slowing enterprise deals, this approach is a good fit. Explore our UI/UX design service or talk to us about your product.