Applying Systems Thinking
Berkeleytime is UC Berkeley’s largest course enrollment platform, serving over 45,000 students. In a recent survey, 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 defined a design system to bridge gaps between design and frontend implementation, ensuring a more cohesive UI across all pages ahead of our beta release Fall 2025.
Role
Design Systems Designer
Timeline
12 weeks; Summer 2025
Team
5 Product Designers
1 Engineer
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.
Context
Why Did We Decide to Build a Design System?
User Research
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.
Conclusion
Reflections
User Research
Design Systems as a Tool for Communication
I see design systems as a shared language that unites teams. They bridge the gap between design and engineering, providing a single SOT that enables faster, scalable product development.
Design Systems as a Living Product
Design systems are their own living product, requiring continuous iteration and maintenance to evolve alongside the product and remain an important resource for the team.