Work

Fun

About

Resume

Thumbnail image

Berkeleytime

Berkeleytime is UC Berkeley’s largest course enrollment platform, serving over 45,000 students. To address small inconsistencies across the platform’s web and mobile interfaces, my team decdied to define Berkeleytime's first ever design system to bridge the gaps between design and frontend implementation, ensuring a more cohesive UI across all pages ahead of our beta release Spring 2026.

Role

Design Systems Designer

Timeline

Jan 2025 - May 2025

Team

5 Product Designers

2 Engineers

Problem

How might we unify Berkeleytime’s web and mobile UI to deliver a seamless student experience and streamline design-to-dev before our beta launch?

Impact

Reusing the design system we created enabled the frontend team to rapidly build new pages and maintain consistent UI updates across all webpages.

Why Did We Decide to Build a Design System?

Inconsistent UI Patterns Diminish User Trust

Some core UI components like buttons and confirmation modals looked and behaved differently depending on the page a student was viewing, causing users to re-learn Berkeleytime's interface constantly.

Lack of Standardized Components Leads to a Slower Development Cycle

A significant amount of time was being wasted on re-building common UI components. Without a centralized library of reusable assets, designers and developers were reinventing the wheel, leading to duplicated effort.

Collaborating with Engineers and other Designers

Codebase and UI Audit

Our first step was to conduct a comprehensive audit of the entire platform. We took inventory of every button, modal, and colors to create a clearer picture of the inconsistencies and identify the most critical components to build first.

Weekly Syncs with Engineers

We had weekly collaborative sessions with the engineering team where we reviewed existing components, discussed their codebase and maintenance challenges, and got their direct input on component structure and naming conventions.

System Foundations

Highlights from Our Component Library

User Research

These UI components were designed to be flexible, accessible, and consistent across all product teams. Each one follows a shared token system and includes guidelines for usage, states, and responsive behavior.

System Foundations

Highlights from Our Component Library

User Research

These UI components were designed to be flexible, accessible, and consistent across all product teams. Each one follows a shared token system and includes guidelines for usage, states, and responsive behavior.

Highlights from Our Component Library

Below, I highlight some of the key UI components were designed to be flexible, accessible, and scalable consistent across all product teams. Each one follows a shared design token system and includes guidelines for usage, states, and responsive behavior.

System Foundations

Highlights from Our Component Library

User Research

These UI components were designed to be flexible, accessible, and consistent across all product teams. Each one follows a shared token system and includes guidelines for usage, states, and responsive behavior.

Learning Frontend

Along the way, I helped make sure our designs were implemented accurately by becoming much more involved in UI engineering, which was a huge learning experience in itself, often using AI tools like Gemini and Claude to help bridge the gap.

Moving Forward

Establishing Ownership

To ensure the design system has ownership, we are hoping to form a cross-functional Design Systems team to regularly to review proposals for new components or changes and make key decisions to ensure the system continues to meet the needs of Berkeleytime.

Treating Our Design System as a Living Product

Design systems require continuous iteration and maintenance to evolve alongside the product. We hope to establish a clear review process that includes checks for accessibility, performance, and adherence to our design principles to make it easy for anyone on the team to suggest improvements or report a bug.