Building a Unified Design System at The Met

The Met’s website ran on three separate technical stacks, each with its own design library. This case study covers how we consolidated into one system during a platform migration, and what changed for users, engineers, and designers.

The Met’s website operated on three technical stacks with separate design libraries. This resulted in:

• Users encountering different patterns for the same interactions across the site.
• Engineers building three versions of new components.
• Designers and PMs whose initiatives were often choked by component and pattern siloes.

A platform migration presented the opportunity to unify around a single standardized design library (at last!).

Overview of what this project is.

I grounded the work in the most modern of the three existing libraries, auditing it rigorously to remove or consolidate variants, resolving usability issues, and streamlining it into a tight system suited to our small team. The new system was implemented through a close partnership with our frontend engineering lead in weekly working sessions, where we made real time decisions together.

One unified design library replaced three fragmented ones.

• Users now have a consistent experience across all (migrated, quantify) pages of the website.
• Formerly-specialized backend engineers now full-stack, shipping frontend work with confidence and speed.
• Designers and engineers onboard more quickly onto the team.
• External vendors and other internal teams now regularly use our library to align with our standards and to stage content mockups.

Overview of what this project is.

1. Establishing a direct partnership with engineering made this possible.
2. Without governance, consistency erodes over time. Without clear engineering accountability for maintaining Storybook or reviewing the implementation of library components in PRs, visually identical components diverged under the hood, creating redundancy, technical inefficiency, undermining the effort that had gone into standardizing around a single design library. (See what I’m doing about this below.)

My role continues to evolve with the system. To bridge the Figma-Storybook divide, I gained access to the codebase and began contributing directly to components and to the organization of components within Storybook itself.

Sometimes we want to break the rules, strategically. I’m working with our Head of Product to establish a clear framework for when to use standardized components versus when to build bespoke solutions for select high-touch experiences.