CASE STUDY
Meridian - Enterprise Design System
Meridian is People Inc.'s centralized enterprise design system that powers the digital experiences of 44 products across the organization. As Product Design Lead, I owned the strategy, architecture, and evolution of the system - establishing a shared foundation that enables designers and engineers to build consistent, scalable, and accessible experiences across multiple business domains.
Rather than creating a traditional UI library, I approached Meridian as an organizational product. The system combines design tokens, Figma Variables, responsive layouts, reusable components, documentation, and governance into a unified platform that accelerates product development while maintaining consistency across brands.
The project focused on solving challenges beyond visual consistency: reducing duplicated effort, improving collaboration between design and engineering, enabling incremental adoption, and creating a scalable foundation capable of supporting future products without requiring teams to reinvent common interaction patterns.
Today, Meridian serves as the shared design language for People Inc.'s product ecosystem, helping teams move faster while delivering a more cohesive user experience across all 44 brands.
Role
Product Design Lead
End-to-end ownership
Industry
Media
Lifestyle
Publisher
Advertising
Tools
Figma
Design Systems
UI/UX
Prototyping
Web design
Branding
Live
I lead the design and evolution of Meridian, the centralized design system powering digital experiences across 44 products within People Inc. Rather than designing a single application, I built the design foundation that enables multiple product teams to create consistent, scalable, and accessible experiences while significantly reducing duplication across the organization. |
The Problem
User Problem
As People Inc.'s product portfolio continued to grow, individual product teams gradually evolved their own UI patterns, spacing systems, typography scales, layouts, and interaction behaviors. Although many products solved similar problems, users experienced inconsistent interfaces when moving between applications, increasing cognitive load and reducing confidence across the ecosystem.
Designers frequently recreated common components from scratch, while engineers implemented similar UI patterns multiple times with subtle variations. Instead of focusing on solving product-specific problems, teams spent valuable time rebuilding the same foundational elements.
Business Problem
As the organization expanded its product portfolio, maintaining visual consistency and implementation quality became increasingly difficult.
Without a centralized system:
Components were duplicated across multiple products.
Product delivery slowed due to repeated design effort.
Engineering implemented inconsistent UI behavior.
Accessibility standards varied between teams.
New product teams lacked a consistent starting point.
Scaling the product ecosystem became increasingly difficult.
The organization needed a reusable, scalable design foundation capable of supporting dozens of independent products while still allowing individual brands enough flexibility to preserve their identity.
Constraints
Meridian needed to support 44 independent products, each with different business goals and user needs.
Existing products could not be redesigned from scratch; migration had to happen incrementally.
Multiple engineering teams consumed the design system simultaneously, requiring stable documentation and predictable implementation patterns.
Brand-level customization had to coexist with a shared design language.
The system needed to support future products that had not yet been designed.
Discovery & Research
Rather than beginning with component creation, I started by auditing the organization's existing product ecosystem.
I reviewed interfaces across multiple products, documenting repeated UI patterns, inconsistencies, accessibility gaps, and opportunities for consolidation. Components were categorized by frequency of use, implementation complexity, and business criticality.
A recurring pattern quickly emerged.
Most inconsistencies were not visual—they were behavioral.
Buttons, navigation systems, forms, layouts, dialogs, spacing, and responsive grids all attempted to solve the same problems but with different interaction models depending on the product team.
This shifted Meridian's direction from becoming "another component library" to becoming the shared language for every product team.
I also collaborated closely with engineering to understand implementation constraints and technical architecture, ensuring design decisions translated directly into reusable front-end patterns rather than remaining isolated Figma assets.
Design Process
1. Establishing Design Foundations
Before creating reusable components, I defined the foundational layer of Meridian.
This included:
Typography scales
Color tokens
Spacing system
Elevation
Border radius
Responsive breakpoints
Grid system
Iconography
Motion principles
Separating foundations from components meant future visual updates could propagate consistently across the entire system without requiring component redesigns.
2. Building a Token-First Architecture
Rather than hardcoding visual values into components, I adopted a token-first architecture using Figma Variables.
Primitive values were abstracted into semantic design tokens, enabling products to inherit consistent behavior while supporting future theming and brand customization.
This architectural decision transformed Meridian from a static UI kit into a scalable design platform.
3. Designing a Reusable Component System
I designed reusable component families covering the most common enterprise interaction patterns, including:
Navigation
Forms
Inputs
Tables
Data visualization
Feedback states
Layout containers
Dialogs
Image layouts
Content presentation
Each component included:
Variants
States
Responsive behavior
Accessibility guidance
Usage recommendations
Interaction documentation
This reduced implementation ambiguity while giving designers and engineers a common vocabulary.
4. Defining Responsive Layout Standards
Instead of treating responsiveness as a final design step, I created a standardized responsive framework defining:
Breakpoints
Grid behavior
Container widths
Image layouts
Adaptive spacing
Responsive component behavior
This significantly reduced layout decisions for product teams while creating consistent experiences across screen sizes.
5. Documentation & Adoption
Recognizing that adoption determines the success of every design system, I treated documentation as a first-class product.
Rather than documenting only what components existed, I explained:
Why the pattern exists
When to use it
When not to use it
Accessibility considerations
Implementation guidance
Migration recommendations
The objective was to reduce interpretation and empower product teams to adopt Meridian independently without relying on continuous design support.
Key Decisions & Tradeoffs
Foundation Before Components
Stakeholders initially wanted reusable components delivered as quickly as possible.
I deliberately invested time establishing the design foundations first.
Tradeoff
Initial progress appeared slower.
Benefit
Every subsequent component inherited a consistent visual language, dramatically improving maintainability, scalability, and long-term system health.
Flexibility Without Fragmentation
Different products required varying levels of customization.
Rather than allowing unrestricted modification—which would eventually recreate inconsistency—I designed a layered architecture where products could customize through semantic tokens while preserving shared interaction patterns.
This balanced brand flexibility with organizational consistency.
Documentation as Product Design
Many design systems fail because documentation becomes an afterthought.
I treated Meridian's documentation as another product surface.
Every guideline answered four questions:
Why this pattern exists.
When to use it.
When not to use it.
How it behaves.
The goal was reducing interpretation rather than simply publishing design assets.
Outcomes
Established Meridian as the centralized design system supporting digital experiences across 44 products within People Inc.
Built a scalable design token architecture using Figma Variables, enabling consistent theming and future product scalability.
Standardized typography, color, spacing, grids, responsive layouts, accessibility guidelines, and interaction patterns across the organization.
Designed and documented reusable components, layout frameworks, image systems, and platform guidelines to create a unified design language.
Reduced design inconsistency by replacing isolated product-specific UI patterns with reusable, governed design foundations.
Improved collaboration between design and engineering by providing a shared system of components, documentation, and implementation guidelines.
Created a structured documentation framework that enables product teams to adopt and contribute to the design system independently.
Established Meridian as the design foundation for future People Inc. products, ensuring new experiences can be built with consistency, scalability, and accessibility from day one.
What I'd Do Differently
While Meridian established a strong technical and visual foundation, I would introduce adoption metrics much earlier in the project.
Initially, success was measured primarily through component completion and documentation coverage. In retrospect, I would establish adoption KPIs from the beginning - such as component usage across products, contribution activity, migration progress, and design consistency reviews.
Building a design system is only half the challenge; driving organization-wide adoption is what ultimately determines its success. Measuring adoption earlier would have provided stronger insight into how teams were using Meridian and helped prioritize future improvements based on real-world usage rather than assumptions.
CASE STUDY
Meridian - Enterprise Design System
Meridian is People Inc.'s centralized enterprise design system that powers the digital experiences of 44 products across the organization. As Product Design Lead, I owned the strategy, architecture, and evolution of the system - establishing a shared foundation that enables designers and engineers to build consistent, scalable, and accessible experiences across multiple business domains.
Rather than creating a traditional UI library, I approached Meridian as an organizational product. The system combines design tokens, Figma Variables, responsive layouts, reusable components, documentation, and governance into a unified platform that accelerates product development while maintaining consistency across brands.
The project focused on solving challenges beyond visual consistency: reducing duplicated effort, improving collaboration between design and engineering, enabling incremental adoption, and creating a scalable foundation capable of supporting future products without requiring teams to reinvent common interaction patterns.
Today, Meridian serves as the shared design language for People Inc.'s product ecosystem, helping teams move faster while delivering a more cohesive user experience across all 44 brands.
Role
Product Design Lead
End-to-end ownership
Industry
Media
Lifestyle
Publisher
Advertising
Tools
Figma
Design Systems
UI/UX
Prototyping
Web design
Branding
Live
I lead the design and evolution of Meridian, the centralized design system powering digital experiences across 44 products within People Inc. Rather than designing a single application, I built the design foundation that enables multiple product teams to create consistent, scalable, and accessible experiences while significantly reducing duplication across the organization. |
The Problem
User Problem
As People Inc.'s product portfolio continued to grow, individual product teams gradually evolved their own UI patterns, spacing systems, typography scales, layouts, and interaction behaviors. Although many products solved similar problems, users experienced inconsistent interfaces when moving between applications, increasing cognitive load and reducing confidence across the ecosystem.
Designers frequently recreated common components from scratch, while engineers implemented similar UI patterns multiple times with subtle variations. Instead of focusing on solving product-specific problems, teams spent valuable time rebuilding the same foundational elements.
Business Problem
As the organization expanded its product portfolio, maintaining visual consistency and implementation quality became increasingly difficult.
Without a centralized system:
Components were duplicated across multiple products.
Product delivery slowed due to repeated design effort.
Engineering implemented inconsistent UI behavior.
Accessibility standards varied between teams.
New product teams lacked a consistent starting point.
Scaling the product ecosystem became increasingly difficult.
The organization needed a reusable, scalable design foundation capable of supporting dozens of independent products while still allowing individual brands enough flexibility to preserve their identity.
Constraints
Meridian needed to support 44 independent products, each with different business goals and user needs.
Existing products could not be redesigned from scratch; migration had to happen incrementally.
Multiple engineering teams consumed the design system simultaneously, requiring stable documentation and predictable implementation patterns.
Brand-level customization had to coexist with a shared design language.
The system needed to support future products that had not yet been designed.
Discovery & Research
Rather than beginning with component creation, I started by auditing the organization's existing product ecosystem.
I reviewed interfaces across multiple products, documenting repeated UI patterns, inconsistencies, accessibility gaps, and opportunities for consolidation. Components were categorized by frequency of use, implementation complexity, and business criticality.
A recurring pattern quickly emerged.
Most inconsistencies were not visual—they were behavioral.
Buttons, navigation systems, forms, layouts, dialogs, spacing, and responsive grids all attempted to solve the same problems but with different interaction models depending on the product team.
This shifted Meridian's direction from becoming "another component library" to becoming the shared language for every product team.
I also collaborated closely with engineering to understand implementation constraints and technical architecture, ensuring design decisions translated directly into reusable front-end patterns rather than remaining isolated Figma assets.
Design Process
1. Establishing Design Foundations
Before creating reusable components, I defined the foundational layer of Meridian.
This included:
Typography scales
Color tokens
Spacing system
Elevation
Border radius
Responsive breakpoints
Grid system
Iconography
Motion principles
Separating foundations from components meant future visual updates could propagate consistently across the entire system without requiring component redesigns.
2. Building a Token-First Architecture
Rather than hardcoding visual values into components, I adopted a token-first architecture using Figma Variables.
Primitive values were abstracted into semantic design tokens, enabling products to inherit consistent behavior while supporting future theming and brand customization.
This architectural decision transformed Meridian from a static UI kit into a scalable design platform.
3. Designing a Reusable Component System
I designed reusable component families covering the most common enterprise interaction patterns, including:
Navigation
Forms
Inputs
Tables
Data visualization
Feedback states
Layout containers
Dialogs
Image layouts
Content presentation
Each component included:
Variants
States
Responsive behavior
Accessibility guidance
Usage recommendations
Interaction documentation
This reduced implementation ambiguity while giving designers and engineers a common vocabulary.
4. Defining Responsive Layout Standards
Instead of treating responsiveness as a final design step, I created a standardized responsive framework defining:
Breakpoints
Grid behavior
Container widths
Image layouts
Adaptive spacing
Responsive component behavior
This significantly reduced layout decisions for product teams while creating consistent experiences across screen sizes.
5. Documentation & Adoption
Recognizing that adoption determines the success of every design system, I treated documentation as a first-class product.
Rather than documenting only what components existed, I explained:
Why the pattern exists
When to use it
When not to use it
Accessibility considerations
Implementation guidance
Migration recommendations
The objective was to reduce interpretation and empower product teams to adopt Meridian independently without relying on continuous design support.
Key Decisions & Tradeoffs
Foundation Before Components
Stakeholders initially wanted reusable components delivered as quickly as possible.
I deliberately invested time establishing the design foundations first.
Tradeoff
Initial progress appeared slower.
Benefit
Every subsequent component inherited a consistent visual language, dramatically improving maintainability, scalability, and long-term system health.
Flexibility Without Fragmentation
Different products required varying levels of customization.
Rather than allowing unrestricted modification—which would eventually recreate inconsistency—I designed a layered architecture where products could customize through semantic tokens while preserving shared interaction patterns.
This balanced brand flexibility with organizational consistency.
Documentation as Product Design
Many design systems fail because documentation becomes an afterthought.
I treated Meridian's documentation as another product surface.
Every guideline answered four questions:
Why this pattern exists.
When to use it.
When not to use it.
How it behaves.
The goal was reducing interpretation rather than simply publishing design assets.
Outcomes
Established Meridian as the centralized design system supporting digital experiences across 44 products within People Inc.
Built a scalable design token architecture using Figma Variables, enabling consistent theming and future product scalability.
Standardized typography, color, spacing, grids, responsive layouts, accessibility guidelines, and interaction patterns across the organization.
Designed and documented reusable components, layout frameworks, image systems, and platform guidelines to create a unified design language.
Reduced design inconsistency by replacing isolated product-specific UI patterns with reusable, governed design foundations.
Improved collaboration between design and engineering by providing a shared system of components, documentation, and implementation guidelines.
Created a structured documentation framework that enables product teams to adopt and contribute to the design system independently.
Established Meridian as the design foundation for future People Inc. products, ensuring new experiences can be built with consistency, scalability, and accessibility from day one.
What I'd Do Differently
While Meridian established a strong technical and visual foundation, I would introduce adoption metrics much earlier in the project.
Initially, success was measured primarily through component completion and documentation coverage. In retrospect, I would establish adoption KPIs from the beginning - such as component usage across products, contribution activity, migration progress, and design consistency reviews.
Building a design system is only half the challenge; driving organization-wide adoption is what ultimately determines its success. Measuring adoption earlier would have provided stronger insight into how teams were using Meridian and helped prioritize future improvements based on real-world usage rather than assumptions.