Shaping a unified design system
Transformed fragmented design systems into a unified foundation for scalable experiences, now supporting enterprise products and adopted across product, design, and engineering teams.
Company:
Zelis
Role:
Product designer
Date:
2021-2023

System matuirty
Distinct and nascent systems
When I joined the company, the two core products operated independently, each with nascent design language system and codebases. Although both systems leveraged Google's Material Design principles, the experiences diverged due to distinct engineering and product design teams, revealing challenges:
Incompatible code repositories duplicated engineering efforts.
Inconsistent design patterns created user confusion and eroded trust.
Project-based team structures limited collaboration, resulting in poor component governance and scalability challenges.

The catalyst
The turning point came when clients began requesting a unified healthcare experience across products aligned with their brand standards. These requests reframed the challenge from isolated product inconsistencies to a platform-level scalability problem, highlighting the need for a shared design language system.
The turning point
Treating the DLS as a product
The momentum to establish a unified DLS was driven by several factors:
Design team growth enabled dedicated resources to focus on DLS research, development, and advocacy.
Leadership buy-in prioritized componentization to enable scalable experiences.
Engineering alignment led to consolidating products and creating a shared component repository.
Establishing shared infrastructure
To support a unified design language system, we established shared infrastructure between design and engineering. Design components were centralized in Figma, creating a single source of truth for patterns and UI structure. On the engineering side, Storybook enabled teams to document and validate components, while an Angular-based monorepo allowed shared UI components to be developed and distributed across products.
Together, this infrastructure transformed the DLS from a design artifact into a production-ready system embedded within the platform.
Operationalizing the design system
Shaping the process to deliver interface at scale
Without a dedicated design-engineering team, the design language system evolved within existing product workflows. I helped move the organization beyond a project-based model by establishing shared governance, strengthening design-engineering collaboration, and integrating research, component development, and product integration. These practices helped product teams adopt the system more consistently and positioned the design language system as a shared platform capability rather than a design artifact.
Designers conduct research to define a product-driven perspective on each component. While weekly design-engineering syncs ensure alignment and refinement.
Figma
Engineers translate Figma designs into coded components housed in a shared monorepo. Each component is documented in Storybook to support reuse, accessibility, and consistent implementation across products.
Storybook
New features adopt system components by default, while legacy elements are gradually replaced.
Product Integration

Building a design system
Designing for scalability in a white-label B2B2B2C platform
Designing a system for a white-label platform required delivering a cohesive, scalable system that supports the variability required across products, clients and third-party integrations. Components needed to adapt to client configurations, APIs and branding, each introducing unique requirements.
In early iterations of the DLS, components became tightly coupled to specific implementations, making them difficult to evolve without creating additional variants. This introduced complexity, inconsistencies, and growing maintenance overhead for both design and engineering.
As the system has matured, components are being restructured to separate structure, behavior and presentation into a composable layers. Through extensible patterns and slot-based composition, components can now accommodate for variability, reducing duplication, improving consistency and lowering overhead.
The result V1
Foundation for scalability
The DLS evolved from two fragmented systems into a unified, scalable framework that enables teams to:



While the system created a shared foundation across products, scaling it across the enterprise required more than reusable components. It required a governance model capable of supporting collaboration across teams.
Evolution and growth
Moving towards a federated model
Following the acquisition, the organization shifted from a centralized design system to a federated governance model supporting alignment across enterprise products. As stewards of the original system, our team guided this transition, and I helped shape governance practices by facilitating cross-team working sessions, defining contribution expectations, and supporting system adoption across teams. These efforts helped position the existing system as the foundation for Lumen, the new enterprise design language system.
As adoption expanded, the federated model surfaced new challenges. Teams operated with different priorities, contribution models were still forming, and the level of investment required to scale the system across the enterprise remained unclear.

The result V2
The design system's impact
While the federated model created a path toward enterprise alignment, shifting organizational priorities limited the team’s capacity to fully operationalize it. Even so, the core design language system continues to evolve as product needs emerge, positioning the system for future scale.
increase in project delivery across design and front-end workflows
enterprise products adopted the Design Language System
employees adopted the Design Language System.





















