About me

Berkeleytime

Built our first design system

Summary

Years of feature velocity without shared components left Berkeleytime’s UI fragmented and design–eng handoff slow. We shipped the product’s first token-based design system, 35+ WCAG-AA components, and saw +18K MAU the semester it landed on high-traffic pages.

My Contribution

I built our foundational design system in Figma with a team of 2 designers, then, as design lead this semester, translated it into a token-based system connecting Figma to code via Storybook. We shipped a 35+ component, WCAG-AA compliant library.

Timeline

From January 2026 to March 2026

Team

1 Design Systems Lead

2 Engineers

2 Designers

Tools

VS Code

Figma

Storybook

Cursor Agent

Skills

User Research

Prototyping

Usability Testing

Frontend

Overview

A shared, token-based workflow reduced design-to-development friction and made Berkeleytime’s UI more consistent.

A 204-person survey revealed recurring issues with broken breadth filters, glitching grade distributions, and missing class sections. Users said these bugs reduced trust in the platform, weakening the reliability that made Berkeleytime preferable to CalCentral, (UC Berkeley's official course enrollment system).

Key Highlights

+18K MAU

Semester growth in monthly active users after the UI / DS rollout

1,157+ → 0 values

Hardcoded across padding, gap, border-radius, and shadow

35+ components

Components built on Radix UI, establishing a 1:1 token structure

Before: Our catalog page built with hardcoded CSS

Inconsistent component rendering, a broken A+ bar, mismatched card styles, and an oversized tooltip, all symptoms of miscommunication between engineers and designers working without a single SOT.

After: A Standardized Catalog interface

Unified data visualization components, consistent card hierarchy, and a cohesive interaction language across different states (active and inactive), shipped using our component library and actively being built in Storybook.

Overview

A shared, token-based workflow reduced design-to-development friction and made Berkeleytime’s UI more consistent.

A 204-person survey revealed recurring issues with broken breadth filters, glitching grade distributions, and missing class sections. Users said these bugs reduced trust in the platform, weakening the reliability that made Berkeleytime preferable to CalCentral, (UC Berkeley's official course enrollment system).

Key Highlights

+18K MAU

Semester growth in monthly active users after the UI / DS rollout

1,157+ → 0 values

Hardcoded across padding, gap, border-radius, and shadow

35+ components

Components built on Radix UI, establishing a 1:1 token structure

Before: Our catalog page built with hardcoded CSS

Inconsistent component rendering, a broken A+ bar, mismatched card styles, and an oversized tooltip, all symptoms of miscommunication between engineers and designers working without a single SOT.

After: A Standardized Catalog interface

Unified data visualization components, consistent card hierarchy, and a cohesive interaction language across different states (active and inactive), shipped using our component library and actively being built in Storybook.

The Problem

Inconsistent UI and repeated product defects had eroded trust among Berkeleytime’s 50,000+ monthly users.

For 50,000+ monthly users, finding and filtering Berkeley courses should feel fast and frictionless, not like piecing together information scattered across inconsistent UI patterns.

Figma Copy-Paste Drift

Without shared production tokens, the Course Card was implemented differently across pages, resulting in variations in typography, color, and spacing.

Inconsistent interfaces traced back to the code

An audit with CursorAgent uncovered hundreds of hardcoded spacing and typography values, alongside references to design tokens that were never defined. Without shared style definitions in code, components relied on individual values and fallbacks, making consistency harder to maintain.

User Insights

A pattern of inconsistent feature updates had fractured user trust over time.

A 204-person survey revealed recurring issues with broken breadth filters, glitching grade distributions, and missing class sections. Users said these bugs reduced trust in the platform, weakening the reliability that made Berkeleytime preferable to CalCentral, (UC Berkeley's official course enrollment system).

Auditing the codebase

Auditing the existing interface revealed the components causing the most inconsistency and user friction.

We quickly identified technical debt, revealing hardcoded values and fragmented styling that degraded the interface's performance and visual consistency.

Establishing shared visual foundations to keep components consistent across Figma and code.

35+ WCAG-AA accessible components across 8 categories, foundations, inputs, call to action, communication, data visualization, lists, containers, and navigation, each documented across interaction states and being actively implemented in Storybook as a live reference for engineering.

1. Shared Foundations

2. Applied to the component

Grade Distribution

A+: 15%
A: 25%
A-: 20%
B+: 15%
B: 10%
B-: 8%
C+: 4%
C: 2%
C-: 1%

Spacing: The shaded bands show the card’s internal padding: 12px around the body and 8px vertically / 12px horizontally around the header.

Designing the solution

Establishing shared visual foundations to keep components consistent across Figma and code.

Standardized spacing, typography, color, and shape gave components a consistent visual language. These shared foundations defined how elements fit together, giving designers and engineers clear rules to carry from Figma into code.

1. Shared Foundations

2. Applied to the component

Grade Distribution

A+: 15%
A: 25%
A-: 20%
B+: 15%
B: 10%
B-: 8%
C+: 4%
C: 2%
C-: 1%

Spacing: The shaded bands show the card’s internal padding: 12px around the body and 8px vertically / 12px horizontally around the header.

A component library gave designers and engineers a shared source of truth.

35+ WCAG-AA accessible components across 8 categories, foundations, inputs, call to action, communication, data visualization, lists, containers, and navigation, each documented across interaction states and being actively implemented in Storybook as a live reference for engineering.

Connecting Figma components to Storybook to give designers and developers a shared reference for design and implementation.

I used Storybook to bring the implemented components into a shared environment where the team could inspect their appearance and interaction states alongside the Figma designs. This made differences between design and code easier to identify and discuss before using the components across product pages.

Connecting Figma components to Storybook to give designers and developers a shared reference for design and implementation.

I used Storybook to bring the implemented components into a shared environment where the team could inspect their appearance and interaction states alongside the Figma designs. This made differences between design and code easier to identify and discuss before using the components across product pages. Link to the live Storybook: https://storybook.berkeleytime.com/

Applying the component library turned fragmented screens into a consistent, easier-to-scan experience.

Before

Course cards used mixed type weights, colors, and badge styles with no shared language

Filter panel lacked hierarchy

No inline way to preview sections or ratings

After

Consistent card components with unified enrollment, grade, and unit display

Structured filter panel with clear groupings, dropdowns, and a range slider

Inline detail panel lets users preview course info, sections, and ratings

Before

Bar colors have no legend or labeling system

No way to identify which course or instructor a data set belongs to

After

Added courses display as color-coded cards with instructor and semester context

Chart bars map directly to each course via consistent color tokens

Before

Multiple enrollment curves with no course labels or color legend

No way to distinguish which line belongs to which course or section

No way to see service status, distance, or availability at a glance

After

Single course view with clear enrollment milestones and waitlist data surfaced

Missing data states handled explicitly with inline tooltip explanation

Course card anchors the chart, instructor, semester, and section all visible at a glance

Impact & Outcome

Reusable UI replaced fragmented patterns across the product, so teams stop reinventing the same screens for each ship.

In the semester we rolled the tokenized library onto Berkeleytime’s highest-traffic pages, monthly active users grew by +18K. Design and engineering now share one source of truth: 35+ WCAG-AA components wired Figma to Storybook, with 1,157+ hardcoded values replaced by tokens so UI no longer drifts release to release. In usability sessions, 20+ comments called out the clearer, more consistent interface.

Key Highlights

+18k MAU

Growth in monthly active users in this past semester

35+ components

Part of our design systems library across Figma and Storybook

20+ comments

Appreciating updated UI through usability testing with students

Next Steps

Next we’re prioritizing where inconsistency still costs trust, extending the token system into flows like notifications.

One of the bigger challenges of building a design system for Berkeleytime was sequencing the work: establishing an audit and working with engineering before building the component library. In terms of next steps, I’m continuing to build out the token systems, including color, type, spacing, and state, so Figma and code stay in sync as the system grows. With foundations in place, the goal is rolling the system into lower-traffic but high-friction pages, including notifications and other secondary surfaces.