Simplifying course planning and comparing lecture options
Carta is a course planning website used by 95% of Stanford students, yet students in multi-lecture courses had no way to pick a specific lecture, losing sight of their schedule. I designed a lecture selection feature from first interview to shipped UI, through 5 interviews, 12 usability tests across 3 rounds, and specs for engineering.
It shipped in spring 2026 and was live for every Stanford student who uses Carta; Carta has since been redesigned, and the current site no longer includes this version.
check out my FIGMA FILE →
MY ROLE
Product Design Intern
TEAM MEMBERS
2 Product Designers
TOOLS USED
Figma
Figjam
Spec docs
TIMELINE
10 weeks
CONTEXT
Carta is Stanford's course planning platform, regularly used by 95% of the student body. Their approach is "Course planning, simplified through student insights."
PROBLEM STATEMENT
Many high-enrollment introductory courses at Stanford, such as Math 51, offer multiple lecture times under a single class listing.
In Carta, the current flow for selecting and adding a specific lecture time to the user's schedule is not supported at all, which can create confusion and ambiguity.
An example of how Carta's lack of multi-lecture support forces students to rely on external scheduling tools and manual workarounds.
SOLUTION OPPORTUNITY
I designed and shipped a multi-lecture course selection feature that makes quarter planning faster, clearer, and more flexible.
The experience balances visibility of multiple lecture options with a clean interface, allowing students to make informed scheduling decisions without sacrificing context.
check out my FIGMA FILE →
USER RESEARCH
Talking to students
I wanted to talk to other students to understand the tools and processes used in schedule planning outside of Carta.
I interviewed 5 students from a variety of background from computer science, design, and human biology and document how they manage it, where they get confused/frustrated within their process, and what can be improved.
Here's what I learned:
Reframed design challenges
Based on these user insights these were the questions I came up with to guide myself throughout the project.
How might we let students know that a class has multiple lectures?
How might we depict a specific lecture in the sidebar calendar?
How might we make a design to give students the freedom to experiment with different times?
COMPETITIVE ANALYSIS
Exploring existing Stanford resources outside of Carta
To understand existing design patterns, I looked at popular Stanford-specific tools like OnCourse and Enrollment Navigator.
BOTH relied heavily on pop-ups or switching between views to check lecture times.
From my user testing, these patterns often caused students to lose context. So one big takeaway was: students need to see the full schedule while making decisions.
Analyzing Carta's design system
Because this feature lives inside Carta, I really wanted my solution design to feel like a natural extension from here. Carta uses:
Stanford's cardinal red as its primary color
card-based layouts
structured whitespace
CLEAN, SIMPLE, NEUTRAL TONE
DEFINING INTERACTION FLOW
Brainstorming and wireframing
I first mapped the feature at the interaction level, determining where actions belonged in the user journey and how transitions should behave.
Based on my research and my own ideation, I prototyped five distinct interaction patterns on paper. after two rounds of lightweight testing with five students, I narrowed the concepts down to the two most intuitive approaches.
Five interaction patterns tested:
Toggle within calendar view
Center modal popup
Dropdown from "Plan" button
Dedicated schedule tab
Search bar dropdown menu
Concept comparison test
(7 participants, qualitative)
After initial paper testing, I narrowed down to two interaction patterns based on feedback from the design team.
I recruited seven new student participants and focused on qualitative signals.
Flow 1, which had a dedicated schedule tab, and flow 2, which had toggle embedded within the sidebar calendar.
Flow 1
Flow 2
Key insights + analysis
Overall, majority of the users preferred calendar toggle because it allowed comparison without losing context.
UI Pattern Exploration
Researching beyond Stanford
I researched course planning tools at peer institutions.
Across many of them, I noticed a consistent pattern: expandable dropdowns with immediate visual confirmation in a calendar view.
SCREENSHOTS OF THE FOUR INSTITUTIONS' COURSE PLANNING WEBSITES
Exploring different interface designs
Some were inspired by peer institution while others built on Carta’s existing collapsible UI patterns. Carta uses collapsible, expandable components, so I prioritized and narrowed down to three concepts (cycled in blue) to prototype digitally.
I narrowed them down to three concepts to prototype digitally.
FOCUSING ON MAINTAINING CARTA'S visual & functional consistency
Defining usability goals and testing
My primary question was deciding which one best supports the most quick and confident swap between lectures to determine schedule fit?
Then I set three secondary testing goals:
Which design minimizes cognitive load and confusion?
Which supports comparison across options most naturally?
Which feels least intrusive in the context of planning a full schedule?
swap pop-up
drop down
simple toggle
Dropdown felt the most clean
and scalable
Participants strongly preferred seeing all lecture times immediately while planning without extra clicks.
So the key takeaway was to use dropdown pattern for this feature and keep the interaction within visual cues.
DESIGN ITERATION
Dropdown creates visual clutter, so I backtracked
However, I realized the dropdown toggle introduced significant visual clutter in the sidebar. It felt crowded and difficult to scan.
three additional iterations
other unsuccessful iterations
FINAL DESIGN
Placing dropdown within overview tab
I landed on the final design of placing dropdown in th overview tab. This way, students keep context while experimenting with different lecture and discussion times.
I used previously unused white space in the overview tab instead of the sidebar, which solve the problem of having to cram all the texts into a small side bar.
It also handles edge cases efficiently: if a class has no discussions the dropdown disappears, and if there’s only one lecture option it simply defaults to that time.
Engineering hand off
I wrote specs for an 8-person engineering team covering the edge cases: a class with no discussion section, a class with a single lecture option, and schedule conflicts. During the build, engineers checked with me to confirm designs, and because I write front-end code, I reviewed the build in the browser and gave notes on spacing and states.
IF I HAD MORE TIME + TAKEAWAYS
A failed iteration is data.
The sidebar dropdown tested well alone and failed in context, because it crammed text into the narrowest part of the screen. I had to step back, revisit the problem, and return to user testing to find a better direction. In both rounds, people wanted to compare lectures without losing their schedule, so context mattered more than which control I picked.
Conduct longer usability testing
I want to run longer-term usability testing during an actual enrollment period with this overview tab. With that I can explore additional edge cases in real course planning workflows.
Next : AI help for schedule conflict
One student in the user interviews revealed that they already use an LLM to plan their quarter. I'd start with highlighting course schedule conflicts, not recommending schedules.