On this page

I led the creation of Prism, an end-to-end design system for a long-term, multi-product financial platform, which included design foundations, a documentation website, and production-ready coded components. After an existing component library failed to scale, I proposed and led a shift toward shared principles, accessibility standards, reusable assets, and system-level guidance. The result reduced rework and accelerated delivery across teams.

The story

I joined a new financial operations platform initiative inside a large financial services organization. The platform was designed to support multiple products and teams and was expected to evolve for well over a decade.

Early on, it became clear that long-term success would depend on more than shipping features quickly. We needed a durable system that could align design, engineering, and accessibility as the platform grew.

The platform launched with an existing UI component library. While it helped teams move fast initially, it wasn’t designed to function as a true design system.

One platform with multiple products, a decade-plus lifespan
Diagram of one platform with multiple products that needed a true design system.

The problem

As more teams adopted the platform, cracks began to show:

  • Design and implementation guidance lived in multiple places
  • No shared design principles or standards on usage
  • Limited documentation and no layout or page-level patterns
  • Inconsistent accessibility support and color contrast failures
  • No reliable, reusable design assets for designers

What initially looked like a tooling issue revealed itself as a system design problem. Teams were repeatedly solving the same challenges, slowing delivery as complexity grew.

Scattered design resources
Scattered design resources living in multiple places

The turning point

As these issues became visible beyond design and engineering, I was asked to evaluate the situation and propose a path forward.

Rather than advocating for a single solution, I framed the decision around trade-offs: short-term speed versus long-term sustainability.

Pros and cons of possible solutions
Pros and cons of possible solutions

The options

I presented three paths:

  1. Extend the existing component library
  2. Make minimal incremental improvements
  3. Invest in a new design system built for scale

The first two options reduced short-term effort but preserved many of the same structural issues. Only a new design system approach addressed accessibility, layout, documentation, and governance at their root.

Evaluating the paths forward
Options 1 and 2 reduce short-term effort but preserve the same gaps. Only Option 3 resolves them at the root.

My recommendation

I recommended option 3: investing in a new design system, what I refer to as Prism. The recommendation was grounded in the platform’s long lifespan, growing product complexity, the cost of rework, and the need for accessibility and consistency at scale. This reframed the work from improving components to establishing a shared foundation.

From design to delivery

Prism was more than a design library. I led and managed the system end to end — its design foundations, a documentation website that made it usable across teams, and the coded components themselves.

To set the quality bar, I built the first version of every component from scratch in HTML, CSS, and JavaScript. Establishing each component in real code let me prove its semantics, accessibility behavior, and interaction patterns before scaling delivery. I then partnered with developers, handing off these working components for them to productionize as Angular components.

Building the components myself first de-risked the system and made the handoff clean: the standard was already defined in code, not just described in a spec.

Prism's homepage

Result

Prism gave teams a shared visual and interaction foundation, clearer standards, and reusable design assets supported by real examples. Accessibility considerations became part of the system rather than an afterthought.

Most importantly, the organization shifted from assembling interfaces to designing within a coherent system, improving both quality and delivery as the platform continued to evolve.

Prism is a fictional name used to describe an internal design system initiative. System names, assets, and internal identifiers have been altered or omitted to remove proprietary or confidential information.