Connect Design System: Code Implementation & Library
Built and implemented the code components for Connect Design System, creating a 1-to-1 match with the Figma library and enabling both engineering and design communities to use the components effectively.
The challenge
After rebuilding the Figma library and creating foundational patterns, the next phase was implementation. Engineers needed accessible, well-documented React patterns for their applications. Designers needed confidence their Figma work would translate accurately to code.
But here's what made this complex: Connect doesn't just support one design system. We build and maintain design systems for multiple teams—including JPO and JPOI, which are client-facing experiences with completely different visual identities. Different colors, different spacing, different roundness. The patterns I built needed to work across all of them.
I'm the only design engineer on a team of 6 engineers total. I implemented over 30 card and form patterns, plus flexible grid patterns to support diverse use cases across the firm—all built to scale across multiple themes.
Implementation approach
I built React patterns by composing our library's base components with TypeScript, matching the Figma library 1-to-1. The technical decision that mattered most: using Tailwind utility classes instead of inline styles. Starting with an established framework that's readable and extensible just makes sense—you want clean code. I mapped our design tokens directly to Tailwind classes, making it easy to inject styling through classNames and keeping patterns maintainable.
Each pattern includes comprehensive documentation and live code examples.
Building for multiple themes
From the beginning, I knew these patterns needed to work across different design systems. Connect internal uses one visual language (we call it topaz-light comfy), while external-facing experiences like JPO and JPOI use completely different theming (solaris). Different colors, different spacing, different border radius—different everything.
The solution: theme files that swap out at the HTML tag level. Change the theme attribute, and the entire visual system updates while the pattern structure stays identical. This meant thinking about patterns abstractly—not "this card has a 12px border radius" but "this card uses our border-radius-md token, which resolves differently per theme."
Being the only design engineer made this work possible. I could contribute on both ends—design and engineering—and act as the bridge between teams. I gave other design teams confidence that their work would translate accurately across themes without them needing to understand the implementation details.
Design-to-code workflow
The patterns give developers a major head start—they don't need to build highly-used UI from scratch. Cards with actions, multi-column forms, responsive grids—these are already solved problems. And developers know design is already happy with them, which is like a cheat code for getting work approved. Just grab the pattern, customize what you need, ship it.
Building these required me to bounce between Figma and code constantly. Sometimes I'd start designing to think through visual logic. Other times I'd jump straight into code to test an idea. I have a coding background, but I'd never built patterns at this scale before. This dual perspective was crucial—I could validate both sides: Does this translate cleanly to props? Will designers understand how to configure this? The patterns work because I experienced both sides of the handoff myself.
Documentation & developer experience
Creating solid patterns was critical for our community, but also for our MCP. When engineers and designers use AI to build their apps, the MCP references these patterns to generate outputs that actually align with our design system standards.
People were constantly asking: "Can this component do X? What props are available? How do I achieve this?" A lot of folks just weren't reading the docs. I redesigned the documentation site and focused heavily on shorter content—FAQs, quick examples, clear usage patterns. Show, don't tell.
Impact
This work shifted how I think about my role. I've always thought in terms of atomic design principles—how small pieces compose into larger systems—but building for multiple themes took it to another level. I wasn't just designing components anymore; I was architecting how patterns scale across an organization and across different visual identities.
The results honestly surprised me. Office hours attendance dropped 30-40%. Connect serves over 2,700 engineers, 716 design teams, 566 applications, 1,800+ code repos, and sees 1.4 million repo downloads. We support two massive business lines—AWM and CCB—plus client-facing experiences through JPO and JPOI. Reducing friction for that many people, across that many visual systems, with a team of just 6 engineers felt significant.
The new documentation and pattern pages answered questions before people had to ask them. Engineers could see how components compose into real UI patterns that work across themes. Build times improved. Design quality went up. Designers stopped worrying about implementation accuracy, whether they were working on internal Connect experiences or external client-facing products.
Combined with the Figma library overhaul, Connect is finally what it should be—design and engineering actually speaking the same language, scalable across multiple brands and visual systems.