Polymath. Design system v3.0
Polymath Design System v3.0 is the component library and design language that powers the Polymath Capital Platform across both the Issuer and Investor experiences. It was built from the ground up as an institutional-grade system for fintech and blockchain products, with accessibility compliance baked in from day one.
I led the design, architecture, and rollout of v3.0, working directly with product designers and engineering to turn it into the shared language of the entire Capital Platform.
Problem
The Polymath Capital Platform served two very different audiences under one product: Issuers, who needed to create tokens, configure compliance rules, manage offerings, and oversee investor activity; and Investors, who needed to browse offerings, complete KYC, subscribe to deals, and manage their holdings. Each side had its own flows, its own complexity, and its own set of edge cases, but they had to feel like one coherent product.
By the time we started work on v3.0, the earlier versions of the design system had grown organically and couldn't scale with the platform's ambition to serve regulated financial markets. Inconsistencies between the Issuer and Investor sides were slowing down design and engineering work.
On top of that, the platform needed to support the white-label model, where institutional clients could launch their own branded versions of the Capital Platform from the same codebase. And none of the existing components had been built with accessibility as a first-class requirement, which is a non-starter for fintech products serving institutional clients who need to meet WCAG compliance for regulatory and procurement reasons. The system needed to be completely rethought: a single source of truth that could power both sides of the Capital Platform, flex across brands through a robust theming architecture, and meet the accessibility standards that institutional fintech demands.
My role
I led the design and architecture of v3.0 end to end. That meant defining the token structure, component hierarchy, documentation standards, and contribution workflows. I started with the foundations: color, typography, spacing, elevation, and motion tokens that could be themed without forking. Every decision at the token level had to work for Polymath's own brand and for white-label clients who needed to launch visually distinct platforms from the same codebase. From there, I built out the component library: forms, tables, data visualizations, modals, navigation patterns, empty states, transaction flows, and all the fintech-specific patterns that don't exist in generic design systems.
The system had to serve both the Issuer workflows, which are dense, data-heavy, and control-oriented, and the Investor workflows, which are more discovery-driven and need to build trust quickly. Every component was designed and tested for accessibility against WCAG standards. That covered color contrast ratios, keyboard navigation, focus states, screen reader support, hit target sizes, and motion preferences. For a platform where users are moving real money and making regulated financial decisions, accessibility isn't a nice-to-have, it's a baseline requirement.
To keep design and engineering in lockstep, we used Storybook as the shared source of truth for coded components. Every Figma component had a matching Storybook entry with the same props, states, and behavior, which meant designers and front-end developers were always working from the same definition rather than interpreting each other's work. This eliminated the usual drift between design files and production code and made component reviews a direct conversation about behavior rather than visual guesswork. I also documented the system thoroughly so that product designers and engineers could adopt it without constant handholding.
Outcomes
Polymath Design System v3.0 became the shared foundation for the Capital Platform across both the Issuer and Investor sides, eliminating the inconsistencies that had slowed down product work between the two experiences.
The theming architecture made the white-label model actually scalable, letting institutional clients launch branded versions of the platform without dedicated design resources per deployment.
Accessibility compliance was built in at the component level, which meant every screen inherited it by default rather than retrofitting it later. This was a strategic advantage in institutional sales conversations where procurement teams asked about WCAG compliance as a gating requirement.
The Storybook integration kept design and front-end in sync as the system evolved, so new components and updates rolled out to both sides of the platform without the drift that usually creeps into mature design systems. The system dramatically reduced design and engineering cycle time, since teams were no longer rebuilding common patterns from scratch for every new feature.
Over time, v3.0 evolved into the operating layer of the Capital Platform: the single source of truth that kept the Issuer and Investor experiences, multiple designers, and engineering teams speaking the same visual and interaction language.
