Berkeleytime
Berkeleytime is UC Berkeley’s largest course enrollment platform, serving over 45,000 students. In a recent survey, some students reported small inconsistencies across the platform’s web and mobile interfaces as we prepared to launch the beta version. To address this, my team and I decided 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
My Role
I was responsible for defining course card interactions across the course catalog, scheduler, and grades & distributions, as well as designing key UI components such as the filter, header, and footer.
Impact
Reusing the design system we created enabled the frontend team to rapidly build new pages and maintain consistent UI updates across all webpages. Check out our (in-progress) assets ↗
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 constantly reinventing the wheel, leading to duplicated effort.
How I collaborated with Engineers and other Designers
Codebase and UI Audit
Our first step was to conduct a comprehensive audit of the entire platform. I took inventory of every button, form, and color to create a clear picture of our 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, ensuring what we designed was practical to build and maintain.
Scaling and Maintaining Consistency
Establishing Ownership
To ensure the design system has clear 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.
Design Systems 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.