Design System

Overview

Advarra’s product portfolio had grown through acquisition, resulting in multiple products, teams, technologies, and design approaches that evolved independently over time.

The challenge was bigger than creating visual consistency. We needed a shared foundation that could support both new product development and the gradual modernization of existing applications.

I led the development of a cross-product design system built around design tokens, reusable patterns, accessibility standards, and governance practices. The system was adopted across five greenfield and two legacy applications, helping teams make more consistent decisions while reducing duplicate design and engineering effort. Because there was no dedicated design system team, the work had to progress alongside active product development — much of the challenge was not creating the system itself, but finding ways to evolve it while products continued to ship.

Problem

Following multiple acquisitions, Advarra had a portfolio of disparate products alongside new applications being developed in parallel. Each product had its own UI patterns, design decisions, and technical constraints, resulting in a fragmented experience across the platform.

There was a clear need to create a more unified “One Advarra” experience — something that felt like a cohesive product ecosystem rather than a collection of separate tools. Simply aligning visual branding (colors, typography) was not enough. At the same time, new greenfield applications needed a scalable foundation of shared components, patterns, and standards that could accelerate development while maintaining consistency.

Constraints

This effort was not a dedicated initiative. It had to be developed alongside existing product responsibilities, which meant time and focus were limited.

Legacy applications were built on different technology stacks, making direct reuse of components difficult and requiring a more abstract, system-level approach to consistency. Existing brand guidelines were geared toward marketing and web presence, not enterprise application design. New product initiatives were actively being developed and needed immediate support, requiring the system to evolve in parallel with ongoing delivery.

The system also had to integrate with existing infrastructure. We leveraged established CI/CD tooling — GitHub for repository management and Artifactory for distributing packages via npm, yarn, and pnpm — while operating at the forefront of evolving internal standards, including adopting pnpm as part of a more modern front-end infrastructure.

Approach

We needed a way to create consistency across products built by different teams, on different stacks, often solving very different problems. Rather than enforcing a single implementation, we focused on standardizing the decisions behind the interface. Design tokens became the foundation — a shared language for color, typography, spacing, and interaction regardless of framework.

Rather than building a full component library from scratch, we selected and customized an existing third-party framework to accelerate adoption. We built a Figma-based system so designers and product teams could iterate quickly using shared components, while token synchronization kept design and code aligned. Accessibility was incorporated from the start, embedded into the system rather than treated as a separate effort. And because new applications were already in progress, we developed the system incrementally.

Team & operating model

As adoption grew, it became clear that maintaining the system would require more than a component library. We needed a way for designers and engineers to make decisions together and resolve questions consistently across products.

I organized a cross-functional group of designers and engineers — informally the Design System Council — to provide a shared forum for evolving standards. We established a working cadence of regular working sessions, broader review meetings, and ongoing showcases, managed through a dedicated Jira board.

Tooling & system management

To support long-term scalability, we adopted Knapsack as a centralized design system platform, providing documentation, implementation guidance, and component governance.

As the ecosystem evolved, we began exploring a transition toward Storybook-based documentation, and toward the end of the initiative, how emerging AI-assisted development workflows might interact with the system. What became clear was that the same structure that helps designers and engineers work together also helps AI tools produce more consistent results: well-defined tokens, documented components, and clear implementation guidance reduce ambiguity regardless of whether the consumer is a developer or an AI assistant.

Key Decisions

1. Prioritizing tokens over components. Given the variety of tech stacks, we standardized at the token level rather than enforcing a single implementation — letting teams adopt the system regardless of framework.

2. Buying speed instead of building everything from scratch. We adopted a third-party component library and customized it, enabling immediate support for new applications.

3. Building in parallel instead of pausing delivery. We “flew the plane while building it,” evolving the system alongside active product development.

4. Embedding accessibility into the system. Compliant patterns were built into components rather than left to individual teams.

5. Aligning design, code, and AI-assisted development through shared tokens. Design decisions in Figma mapped directly to implementation, reducing ambiguity for engineers and emerging AI workflows alike.

Accessibility as a system-level requirement

Rather than treating accessibility as a downstream audit, we embedded it directly into the foundation. We defined design tokens with predictable contrast ratios so color combinations met requirements by default, and at the component level prioritized semantic HTML with ARIA where necessary — allowing teams to adopt accessible patterns by default and significantly reducing compliance risk for customers operating under ADA requirements.

Outcome

The design system gave teams a shared foundation for making decisions across a growing product portfolio. Before the system, teams often solved similar problems independently, resulting in inconsistent experiences and repeated effort. As adoption increased, designers and engineers spent less time debating foundational patterns and more time on product-specific challenges.

The system was adopted across five greenfield and two legacy applications, creating a more cohesive experience while reducing fragmentation. Accessibility became easier to implement consistently because compliant patterns were built into the foundation. Governance, tooling, and shared processes enabled the system to continue evolving, and its structured foundation of tokens, patterns, and component definitions improved the ability of both developers and AI tools to generate consistent implementations.

Reflection

One of the biggest challenges was balancing investment in the system with the immediate needs of product delivery. Because this work was done alongside active development, progress was incremental and often constrained by competing priorities. While we didn’t move as quickly as we might have with dedicated focus, we intentionally prioritized establishing the right foundations — tokens, tooling, and governance — which made it significantly easier to scale the system over time.

Toward the end of the initiative, AI-assisted design and development tools began gaining traction. What struck me was how much these tools benefited from the same things people do: clear structure, consistent definitions, and well-documented decisions.

Whether supporting designers, engineers, product teams, or AI tools, reducing ambiguity creates better outcomes.

If I were continuing this work today, I would place greater emphasis on component metadata, Storybook integration, and AI-consumable documentation — not because AI changes the purpose of a design system, but because it increases the value of having a well-governed one.