Michael Rossi
All work

TIAA

Scaling an enterprise financial design system

TIAA's product groups were each rebuilding the same components a little differently. As the Experience Design Lead, I set the standards, the states, and the governance, then made the system easy enough to adopt that teams stopped forking it.

Company
TIAA
Role
Experience Design Lead
Industry
Financial services
Timeline
2023 – 2024
Every interactive component was specified across its full range of states, so behavior stayed consistent no matter which team built the screen.

Context

TIAA runs a large set of web and mobile products serving customers, advisors, and internal teams across retirement, banking, and investing. Multiple product groups were designing the same patterns in slightly different ways, which slowed delivery and made the experience feel inconsistent from one product to the next. The work set out to give every team a shared, dependable foundation to build on.

The problem

Duplicated components and one-off patterns meant teams rebuilt the same buttons, forms, and interaction models over and over. Quality varied, accessibility was uneven, and no one owned the shared patterns. The hard part was not drawing components. It was building a system flexible enough for very different products while keeping enough governance that it did not fragment the moment teams started using it.

Components were built as themeable primitives, so one foundation could flex to different products without being rebuilt.

What I did

  • Led the design system across web and mobile products as Experience Design Lead
  • Set the component standards, states, and interaction patterns other designers built from
  • Partnered with designers across product teams to bring their components into one governed system
  • Worked with engineering and product leadership on governance, adoption, and roadmap

How I approached it

  • Audited the existing patterns across products to find the real overlaps and the true one-offs
  • Defined a contribution and ownership model so teams could extend the system without forking it
  • Documented usage, states, and accessibility expectations so adoption did not depend on a hallway conversation
  • Built components as reusable, themeable primitives rather than fixed screens
  • Held accessibility and responsive behavior as requirements, not enhancements
Documentation and a clear contribution model made the system something teams could adopt and extend on their own.

Key decisions

  • Gave every shared pattern a clear owner and contribution path, so it had a home and stopped drifting
  • Invested in documentation early, because a system only helps if people can adopt it without you in the room
  • Designed components to flex across very different products without fragmenting ownership
  • Chose long-term maintainability over short-term convenience, even when it slowed a single release

Systems & patterns

  • A component library with defined default, hover, focus, pressed, and disabled states
  • Interaction patterns and selection models teams could reuse across regulated products
  • Accessibility written into the component specs so it carried forward automatically
  • Documentation and a governance structure the internal team could maintain and extend

What shipped

A governed, reusable component and interaction-pattern system, with documentation and a contribution model designed for the internal team to maintain and extend after the initial work.

Reflection

The interesting challenge here was governance, not visuals. A system that is too rigid gets ignored; one that is too loose fragments within a quarter. Most of the work was finding that balance and making adoption easy enough that teams chose the system on its merits. It is a good example of how I think about design at scale: fewer, better decisions that hold up as more people build on them.