Building a shared foundation for Zipline

ZUI existed, but it wasn't functioning as a true design system. Components were routinely copied and modified, patterns had drifted apart, and the Figma library no longer reflected how the product was actually being built.

Engineering had many of the same problems. Common interface patterns existed as repeated pieces of code rather than shared components, with little alignment between design and implementation.

I joined the Foundations team specifically to rethink that model — rebuilding ZUI as a shared product foundation that could make design faster, give engineering something consistent to build toward, and begin addressing years of visual fragmentation across the product.

The Problem

Zipline already had a design system, but it had fallen behind. It wasn't fully componentized, it hadn't kept up with Figma's newer design-system standards, and it didn't use any kind of slotting model.

Underneath, the library worked as a copy-and-paste model with no true shared structure. Without a real foundation to build on, designers ended up creating their own versions of components — and those versions steadily drifted apart from the shared library over time.

The result was a system meant to create consistency that was quietly producing the opposite.

The Approach

I rebuilt ZUI as a Figma component library using a slotting and anatomical component structure.

Every component starts from a base, anatomical component that manages its architecture, properties, and structure. A final component then sits on top and applies the styling layer. Separating structure from styling meant the system could evolve — properties could change, styling could be refined — without breaking the compositions built on top of it.

That structure also made the everyday work faster. Consistent naming conventions, fewer anti-patterns, and a real slotting model gave designers a predictable set of parts to assemble compositions from, instead of rebuilding the same elements by hand.

Anatomical Components

At the center of the new ZUI architecture was a separation between component anatomy and component appearance.

Each component began with a base anatomical layer responsible for its structure, properties, relationships, and available slots.

A styled component then sat on top of that foundation and applied the visual treatment.

This wasn't a replacement for Figma variants. Variants still described meaningful component states and configurations where appropriate.

The architectural decision addressed a different problem: how the component itself should be constructed.

By separating structure from styling, we could evolve the visual language without continually rebuilding the underlying component architecture. Likewise, improvements to the anatomy could propagate through the system without requiring designers to reconstruct every composition that depended on it.

That gave ZUI a much more durable foundation for change.

Composition Instead of Copy and Paste

The previous library encouraged designers to duplicate finished examples and modify them for their use case.

The new system shifted toward composition.

Slots and shared anatomical components gave designers predictable areas where content, actions, icons, controls, and other components could be inserted without detaching or recreating the underlying pattern.

This allowed the system to support variation without introducing a new component every time the product required something slightly different.

It also reduced one of the biggest sources of design-system drift: a designer shouldn't have to break the system in order to use it.

Tokens and Customer Branding

Zipline is used by many different companies, each of which can bring its own brand into the employee experience.

That meant branding couldn't be treated as a layer applied after the interface was designed.

It needed to exist inside the system.

I established a more deliberate token architecture for color, typography, spacing, and other shared values, including the areas where customer branding was permitted to influence the experience.

That allowed designers to preview interfaces using customer themes while also making those same affordances explicit for engineering.

The goal was to support customer identity without allowing customization to undermine hierarchy, readability, or accessibility.

Owning the System

My responsibility for ZUI extended beyond creating components in Figma.

I owned the system end to end, including auditing existing patterns, rationalizing components, defining naming conventions and component APIs, establishing tokens, documenting usage, improving accessibility, creating contribution and review practices, supporting designers, and working directly with engineering on implementation.

Governance was particularly important.

A system only remains useful if teams understand when to reuse an existing pattern, when to extend it, and when a genuinely new component is required.

Rather than treating ZUI as a finished library, I treated it as an evolving product — one that needed maintenance, documentation, adoption, and a clear relationship with the product roadmap.

Creating Alignment with Engineering

Engineering didn't have a mature shared-component foundation when the work began.

That meant design wasn't simply documenting an existing implementation.

ZUI also became a specification for what the shared product architecture could become.

I worked closely with engineering to establish common naming, component boundaries, token usage, behavior, accessibility expectations, and composition models.

Over time, that gave engineers a clearer set of patterns to componentize while reducing the translation required between Figma and production.

The objective wasn't perfect one-to-one parity.

It was reducing unnecessary differences between how designers thought about the interface and how engineers built it.

Supporting Two Products at Once

Rebuilding a design system inside an active product creates another challenge: the old interface doesn't disappear while the new system is being created.

For a period of time, designers needed to support both.

ZUI maintained the legacy patterns required by existing product areas while simultaneously introducing the system that would support Zipline's refreshed experience.

That allowed product teams to continue delivering work without forcing a company-wide migration before the new foundation was ready.

As refreshed areas of the product came online, teams could progressively move toward the newer architecture rather than treating the transition as a single redesign event.

The Outcome

The clearest immediate effect was on the design team's workflow.

When the team reviewed the amount of time required to move work from an initial concept through mockups and into stakeholder-ready deliverables, they reported that getting a deliverable from zero to one was roughly 45% faster on average.

That improvement wasn't about making designers draw faster.

It came from removing decisions they shouldn't have needed to make repeatedly — which component to use, how it should be structured, how spacing should work, which pattern was current, or whether they needed to create something from scratch.

ZUI also became the foundation for Zipline's broader product refresh and gave engineering a clearer architecture to componentize around.

The larger goal was always bigger than a Figma library.

It was to make consistency the default — in design, in code, and ultimately in the product customers use.