Design Systems & Component Architecture

 

Unifying Penn State’s Web Brand Through a Scalable Design System & Component Architecture

When I joined the Penn State web ecosystem, one of the biggest challenges was obvious: the University’s digital presence was fragmented. Every college, department, and marketing team operated its own website with its own interpretation of the brand. Colors were inconsistent. Typography varied wildly. Layouts and UI patterns didn’t match from one domain to the next. And because none of these front ends were built in React, there was no shared foundation—no reusable components, no common design language, no scalable way to deliver updates across the entire organization.

This fragmentation created real problems. Designers couldn’t trust that their work would translate into production. Developers rebuilt the same UI patterns repeatedly. Brand governance was impossible. And each site’s frontend essentially became a bespoke one-off build.

My role was to fix this.

Design System Definition: Establishing a Single Source of Truth

The first step was creating a unified design system that could be applied consistently across every Penn State site.

I connected our Figma design definitions directly to code using a JSON token pipeline. These tokens—colors, typography, spacing, radii, elevations, interaction states—were transformed into CSS variables and served as the foundation for every component in the system. This ensured that brand decisions made in design automatically propagated into all applications.

This alone dramatically reduced variation and guesswork. But it also set the stage for what came next.

Building the Front-End Component Library From Scratch

Because there was no existing React codebase, I engineered the entire component library from the ground up.

This included:

  1. Base UI primitives (buttons, inputs, surfaces, layout primitives, etc.)

  2. Accessible interactions, keyboard flows, and focus management

  3. TypeScript-driven APIs and prop definitions

  4. Consistent styling driven entirely by design tokens

  5. A composable architecture suitable for enterprise multitenant sites

Every component was engineered with accessibility as a baseline expectation—not an afterthought. This ensured the system was inclusive, compliant, and reliable across every device and user environment.The Results

Editorial Components for CMS-Driven Content

On top of the base components, I created a set of higher-level editorial components that content authors could configure and deploy through our CMS (Contentful). These included:

  1. Hero banners

  2. Card collections

  3. Sliders and media components

  4. Dynamic content stackers

  5. Callouts, announcements, and interactive blocks

For the first time, Penn State’s content teams could use consistent, brand-safe components across multiple domains—without requiring custom development for each site.

A Monorepo & Modular Package Architecture for Scalability

To support dozens of sites and teams, I restructured the entire frontend into a modular monorepo design.

Packages were split into:

  1. Design Tokens

  2. Base UI Components

  3. Editorial Components

  4. Shared Utilities

  5. Federated Web Components

  6. Storybook Documentation

This architecture allowed us to version components, ship updates safely, and apply changes across all downstream applications with minimal friction. It also opened the door to federated and cross-site consumption of components.

Federated Components for Cross-Campus Distribution

Some components needed to be consumed outside our monorepo—for teams using older stacks, vendor-built sites, or standalone projects. To support this, I built a federated component layer using both:

  1. Web Components, and

  2. NPM-distributed packages

This allowed Penn State’s design system to extend across the organization even when teams weren’t adopting React or the Next.js framework.

Multitenant Storybook for Documentation & Governance

A system like this only works if teams understand how to use it.

I defined and implemented a multitenant Storybook setup that includes:

  1. Interactive component previews

  2. Variants and accessibility tests

  3. Token documentation

  4. Usage guidelines and implementation notes

  5. API references tied to each TypeScript definition

This became the core governance tool for both designers and developers, giving them a centralized hub to understand how the system works and how each pattern should be implemented.

The Result: A Unified, Scalable, Brand-Consistent Foundation

The outcome of this work was a fully unified design system and component architecture capable of supporting every Penn State property—from admissions to academic colleges to administrative sites.

We went from:

  1. No React usage → a full component ecosystem

  2. No shared components → a distributed, enterprise-ready library

  3. Inconsistent brand execution → design tokens and Figma-to-code pipeline

  4. Isolated websites → monorepo architecture + federated distribution

  5. No documentation → a governed, living Storybook system

More importantly, Penn State now has a sustainable foundation that scales, evolves, and stays consistent across every domain.

Next

Myriad