Skip to main content

B2B Company Registration: A/B Redesign

Senior Frontend Engineer · 2025 · 2 min read

Redesigned company registration as a microfrontend and promoted it after an A/B test beat the live flow on conversion.

Rejected path: Switch everyone at once behind a feature flag, with no A/B traffic split

Overview

With product and backend, I rebuilt a high-friction company registration flow as a microfrontend on the existing Storybook design system. We ran it against the live flow with Unleash before promoting it. Goal: fewer steps, same data, no broken funnel.

Problem

The legacy registration flow had extra steps that caused drop-offs before companies finished their profiles. The monolith was also hard to maintain and out of step with the component patterns used on newer B2B products.

Constraints

  • Had to run beside the live flow during the A/B test, not as a hard cutover.
  • The new flow had to beat the old one on conversion before we promoted it.
  • Shared Storybook design system was the UI source of truth. No parallel component library.

Architecture

Rebuilt registration as a standalone microfrontend and removed unnecessary steps. UI came from the shared Storybook system. Unleash split traffic between old and new. When conversion favored the new version, it became the default.

Key Decisions

A/B test via Unleash instead of direct cutover

Reasoning

Registration is a conversion-critical path. Real traffic decided which design won.

Alternatives considered
  • Switch everyone at once behind a feature flag, with no A/B traffic split (rejected: no conversion proof)
  • Gradual CSS restyle of the monolith form (rejected: did not fix step count or deploy coupling)

Microfrontend plus shared design system

Reasoning

Independent from the monolith for faster iteration. Reusing Storybook components kept focus on flow and logic, not rebuilding UI.

Alternatives considered
  • Rebuild inside the monolith (rejected: slower iteration, higher blast radius)
  • Greenfield UI kit for this flow only (rejected: duplicate tokens and drift)

Tailwind for styling speed against the existing system

Reasoning

Tailwind was already the design-system standard. Layout iteration stayed inside that system instead of inventing a parallel CSS approach.

Alternatives considered
  • Hand-written CSS modules (slower against an existing Tailwind system)

Tech stack

  • React
  • TypeScript
  • Astro
  • Tailwind CSS
  • Storybook
  • Unleash (A/B Testing)
  • Jest
  • React Testing Library

Impact

Rollout method Unleash A/B → promote winner
Funnel change Fewer steps, same required data
Deploy boundary Independent microfrontend (not monolith)
Promotion gate Live conversion beat legacy before default

The A/B test favored the shorter funnel; we promoted it after conversion beat legacy. Unit tests covered the funnel steps because this path sits on onboarding.

Learnings

  • A/B testing a multi-step funnel is messy because conversion is delayed. That is exactly why real traffic matters more than gut feel.
  • A documented design system removes UI as the bottleneck so iteration time went to funnel steps and logic, not rebuilding UI.
  • Removing steps we thought were required was the biggest UX win.