Fiserv – Scaling a Design System Across Products

Scaling a Design System Across Products

Fiserv had already invested in an externally designed system and mandated it across its B2B products. While modernizing Client Central, I found that the system did not support the dense workflows, interaction states, accessibility requirements, and implementation guidance enterprise teams actually needed. I audited 18 products, built a research-backed replacement foundation, and helped scale it across four portfolios and 18 product teams.

My role: I independently designed the initial system—approximately 80 components plus the underlying color, typography, spacing, interaction, and accessibility standards—then established the documentation and governance model that allowed participating teams to expand it to approximately 145 components. I partnered with design leadership to secure adoption and later transitioned ongoing ownership to a dedicated team.

18 Product Teams

Expanded from three initial products to 18 participating product teams within six months.

4 B2B Portfolios

Evaluated and supported across four enterprise product portfolios.

~80 → 145 Components

I built the initial foundation; teams extended it through governed contribution.

Design-to-Development

Included behavior, accessibility, usage rules, and soft coded implementation assets—not only visual examples.

A Mandated Design System That Did Not Fit the Work

Fiserv had contracted a shared design language intended to standardize its B2B products. The delivered system reflected relatively simple interface patterns and provided basic visual styling, but it omitted many of the workflows, interaction states, layout rules, accessibility requirements, and implementation details required by dense enterprise applications.

Client Central was the first product I owned where those limitations became impossible to ignore. Instead of treating them as exceptions for one product, I documented the recurring gaps and investigated whether other teams were encountering the same constraints.

The problem was not resistance to standardization – the proposed standard did not support the products and teams mandated to use it.

Researching What the Enterprise Actually Needed

I began with a requirements audit of Client Central, comparing the mandated guidance against actual workflows, interface states, business rules, accessibility needs, and implementation constraints.

I then evaluated 18 B2B products across four portfolios and reviewed recurring needs with designers, developers, product owners, stakeholders, and users. The audit separated common enterprise patterns from product-specific exceptions, identified missing or inaccessible components, and established which elements should be standardized, configured, created, or preserved.

This changed the discussion from visual preference to system requirements. Leadership could see which patterns recurred across products, which existing elements remained useful, and where a research-backed alternative was necessary.

Turning Product Evidence into an Enterprise Capability

I built the initial foundation myself: approximately 80 components plus color, typography, spacing, interaction, and accessibility standards grounded in the cross-product audit. I connected each proposed pattern to a recurring product need, developed the replacement case, and partnered with design leadership to secure organizational support.

After approval, I designed an internal documentation platform that a developer built from my designs. It provided designers with reusable components and usage rules while giving developers behavior specifications, accessibility requirements, implementation guidance, and coded assets that could be applied across legacy and modern environments.

This moved the work beyond a visual library. Teams gained a delivery resource they could use, extend, and implement without repeatedly reconstructing the same product decisions.

Making the System Usable and Governable

The system needed to support multiple products without becoming another rigid mandate. I structured the documentation around the decisions teams made during delivery: when to use a pattern, which variants were permitted, how it behaved across states and breakpoints, how accessibility was enforced, and how developers could implement it consistently.

A cross-portfolio council reviewed additions and changes. Each portfolio was represented by a lead designer or portfolio owner; teams submitted missing-component requests to a shared backlog, collaborated on the solution, and verified accessibility with checklists and contrast-simulation tools before release. Monthly versioned releases created a predictable cadence and allowed the system to evolve without fragmenting.

As requests slowed and the library matured, ownership shifted toward framework and implementation support for environments including React and Angular. I then transitioned ongoing maintenance to the head of design for a larger, more mature portfolio.

Scaling the System Across 18 Product Teams

The initiative began with three products: my own and two I supported through a colleague. Within six months, leadership established it as the standard for new B2B work, expanding participation to 18 product teams across four portfolios. The foundation I built grew from approximately 80 components to approximately 145 as teams proposed and contributed additional needs through the governance model.

Adoption was meaningful but intentionally bounded. The system was applied primarily to new and in-progress redesigns rather than retrofitted onto live products, and customer-facing white-label products such as Clover and Zelle retained their own brandable systems. Teams were expected to use the shared standard, but adoption was easier because the evaluation had included their requirements and the replacement solved recurring problems the original system had not.

The lasting outcome was not only a larger component library. Teams gained an extensible foundation for complex enterprise workflows, clearer design-to-development handoffs, and a governed way to introduce new patterns without recreating the same decisions product by product.

Common Questions

How did you challenge a system that had already been paid for?

I did not frame the issue as a matter of visual preference. I audited 18 products, documented recurring gaps, accessibility failures, and implementation constraints, then built a working alternative and presented the before-and-after case with the head of design. The decision was based on product evidence and a viable replacement path—not opinion.

What did you personally design, and what did others own?

I independently designed the initial approximately 80-component foundation, the core visual and accessibility standards, the documentation experience, and the governance model. A developer built the internal platform from my designs and enabled coded assets. Product teams later proposed and contributed additional components, and ongoing maintenance eventually moved to a dedicated design organization.

How did you prevent fragmentation across 18 teams?

Changes went through a cross-portfolio council and shared backlog. Teams collaborated on missing patterns, verified accessibility before release, and received monthly versioned updates. This preserved a shared foundation while allowing approved configuration and product-specific exceptions.

Was adoption real or only mandated?

Leadership established the system as the standard for new B2B work, so adoption was not purely voluntary. However, teams continued to contribute because the system reflected requirements they had helped surface and reduced repeated work around enterprise tables, forms, states, and implementation guidance.

What evidence shows that it improved delivery?

The evidence is primarily qualitative: repeated requests and clarification questions declined, and teams stopped rebuilding the same table and form patterns for each product. I did not capture a controlled time-savings metric, so I describe the result as reduced duplication and clearer handoffs rather than claiming a quantified productivity improvement.