Over several months, I led design for the core fleet of planning features for Carta – Stanford's official academic scheduling and exploration platform used by 95% of Stanford's undergraduates.
This project is currently in the middle of user testing, so stay tuned to see further updates and eventual the final product!
For the past few years, Carta – a popular course-planning website where students can read course reviews and create schedules – has been a prominent touchpoint in the academic endeavors of 95% of Stanford undergraduates. In Winter 2020, the team of researchers at Carta realized that the platform needed a facelift, recruiting 13 students to do so.
Joining the design team in the Spring, I began working on one core component of the redesign: overhauling the often overlooked Planner feature, where students can plan their 4-year academic schedules at Stanford.
Breakdown the academic planning process into its most granular components.
Ideate, prototype, user test, iterate, repeat... repeat again... and again, etc.
Throughout, work closely with the dev team, Carta researchers, and Stanford registrar to bring a world-class academic planning experience to the Carta platform.
Conducting thorough qualitative research + obligatory affinity mapping, engaging with CartaLab researchers, running quantitative research on the broader student population, ideating and organizing core features to design.
Joining the design team in the Spring, I began working on one core component of the redesign: overhauling the often overlooked Planner feature, where students can plan their 4-year academic schedules at Stanford.
When all was said and done, we had 15 transcripted interviews from which to extract insightful quotes.
With easily over 300 quotes to pore over, Kristina iterated through rounds of affinity mapping to organize them and illustrate trends and patterns. I created my own Affinity map with her higher level organization to make sure I maximized my own comprehension.
Around this time, I reached out to Carta researchers (in the CartaLab research group) to learn about their academic planning findings on their research group of 100 freshman students.
I also read up on two research papers, “Choices, Identities, Paths: Understanding College Students’ Academic Decisions” and “Course Consideration: Understanding Undergraduate Course Consideration”.
The sheer notion of "4-Year Planning" is a fallacy. No matter how much long-term planning a student has done, they always need to make adjustments during the quarterly enrollment season.
Students analyze their quarter goals, be it time commitment, GPA, interest only, balance between two subjects, etc. throughout planning to try to build up a quarter that meets those goals.
“Must-take” = courses that need to be taken a certain quarter for their major or degree fulfillment. Students then plan their secondary "filler" courses around those must-take courses that are locked in.
Planning a quarter schedule is all about fitting courses in around logistical constraints, conflicts, and preferences.
On average, students go from a "consideration set" of 12 courses to an "enrollment set" of 4 courses from registration opening to the add/drop deadline (the last day you can still change your enrolled schedule).
Students make sure they're planning out the "skeleton" first: the "must-take" classes and sequences that ensure graduation on time based on requirements.
Many students, especially those who haven't yet declared a major, find value in outlining different plans to gauge feasibility and prepare for each possible path.
Students plan out their 4 years in whatever way they see fit, which leads to a diverse array of approaches.
– CartaLab researcher
Stanford only releases scheduling information for classes (who's teaching what, what are the class-times, what quarters is a class offered, etc.) for the CURRENT academic year.
The term “4-Year Planning” is a widely popularized term at Stanford, and it’s exactly what you might think. For most students, at some point in their undergraduate education, they plan out which classes they are taking and when on a spreadsheet to signify their “4-Year Plan”.
To better understand the nuances of the 4-Year Planning approach, our design team broadcasted emails throughout various cross-sections of the undergraduate population, asking them to send in screenshots of their 4-Year Plan.
Students color coordinate to distinguish the different purposes classes have (major, WAYS, must-take, etc.), and oftentimes label those distinctions on the 4-Year grid itself.
Students frequently maintain databases of courses that they're interested in based on various goals and information. As one student in our interviews put it...
– Interviewee 3
It was common to see students tracking their degree requirements progress adjacent to their 4-Year grid to ensure quicker cross-referencing. Students would often transcribe information about different requirements (i.e., "Take 3 classes from this list.") here. To ensure congruence with the 4-Year grid, classes here would sometimes be labeled either "Taken", "Planned", or "Not Planned".
At this point, since we were drawing from in aggregate over 200 research subjects, we utilized user personas to catapult us into the ideation phase.
Christian is a wide-eyed freshman with various academic interests. He wants to make the most of his education, but is not sure what path to pursue.
Excited to explore the intellectual opportunities abundant on campus.
Realizes he doesn't want to completely ignore his other "fuzzy" curiosities and aptitudes.
Dreads the idea of comitting a major for 2+ years and avoids creating a 4-Year Plan at all costs.
Tries to 4-Year Plan but is overwhelmed and confused with the never-ending web of contingincies.
Larry is a senior who's taken a more spontaneous and carefree approach to academic planning, often taking classes just because his friends were or he'd heard that "the professor gives easy As!"
Despised the seemingly complicated degree planning process that he saw other students following.
Struggles each enrollment season because he doesn't have a long-term plan or list of interested classes to turn to.
As graduation nears, he chastises himself for his lack of intentionality.
Regrets not taking certain classes and exploring majors just because he'd wished for an "easier" way to plan.
Olivia is a junior majoring in Biology who plans obsessively. In downtime, she plans for fun, obsessively analyzing pro/cons lists and sandboxiing multiple paths simultaneously.
Wields the mindset: "this is MY education, so I'm going to maximize it".
Treats long-term planning as a full-time job, yet fatigue openning up 7+ tabs to do so each time makes her dread the process.
Struggles each enrollment season to choose a quarter schedule from the multitude that she has sandboxed.
Wonders desparingly if all of her efforts are worth it.
We decided that, in alignment with the overall direction of Carta’s redesign, that Confused Christian would be our primary user persona to design for. Once Christian steps foot on campus, it is his existential angst that we most want extinguished via our planning experience!
With this core group of users to design for, our design team devised a set of “How Might We” statements to guide our brainstorm. Each statement we used to summarize a key pain-point in the academic planning process that at least one of our personas faces.
Another key Design Thinking tool that we relied upon was the Difficulty/Importance matrix which allowed us to settle upon a definitive set of functionalities and features with which to focus on moving forward.
At this point, we began organizing our highest-priority ideas into tangible views, views informed and inspired by our quantitative research and the Carta V1 platform.
The 4-Year Planner, like the 34 4-Year plans we received in our quantitative research, is where users engage in long-term planning, updating their requirements progress, extracting courses from a Saved database, sandboxing different academic paths, among other key pieces of functionality.
The QuarterView is the workbench for students to build up their quarter schedule, playing a form of academic “Tetris” as they choose class-times and plan around non-academic constraints. If they’ve made a 4-Year Plan elsewhere, it is the QuarterView where they turn that plan of considered courses into the reality of an enrolled schedule.
Carta V1, primarily a course exploration platform, allowed students to plan short-term (in a fixed-position sidebar) while they browse through courses. We agreed that this view would persist in the re-design because it would bridge the course browsing experience with the planning experience.
Researching analogous UI, building grayscale prototypes based on previous insights, realizing the long-term planning experience.
In order to begin designing the 4-Year Planner, I chose to look at both Google Calendar and Apple’s Calendar app (aka, Apple Calendar). These interfaces offer users a place to visualize, organize, and plan a diverse array of events and schedules around multiple contingencies – strikingly similar functionality to our 4-Year Planner.
Similar to the trends we saw in our Quantitative research, both interfaces allow users to categorize events into different “calendars”, each with a unique color that tags relevant events. Users can filter these categories to view a subset schedule.
Users can quickly toggle between Week, Month, and Year views, for example, to show event content at different temporal durations to best suit their use case in that planning session.
Regardless of their temporal view, every event, upon selection, displays a callout which elaborates on event detail. Users can edit event settings in this manner.
To account for the spontaneity and flexibility of short and long-term planning, both calendars offer dragging functionality for their events.
68% of 4-Year Plan screenshots were formatted with academic years as rows and quarters as columns, so we replicated this layout to align our Planner with most students' mental models.
Reducing complexity and real estate, I tagged (and color-coordinated) classes based on 1 metric: the requirement(s) that it is fulfilling in the requirements section. As we learned, students’ main priority was requirements-tracking. This would also enforce congruence between the grid and the Requirements section that students crave.
Aligning with the Google/Apple calendars, we knew that draggability would vastly improve the UX of the planning experience so that users could quickly reorganize their classes on the grid.
Tabs was a convention extremely analogous to the multiple tabs for plans frequently seen on the spreadsheet files we recieved.
In Airbnb, if a user wants to save a stay for future consideration, users can save it to categories that they create themselves!
Because there seems to be a variety of use cases for “saving a class to Saved” (i.e., some users save classes for use cases as niche as if they end up pursuing a Data Science minor), the Airbnb approach, rather than saving courses to predefined categories or to a generic database, seemed very robust for our users.
Aligning with a trend in the 4-Year Plan screenshots and because of a lack of available real estate on a standard desktop screen, I decided that the Requirements section and Saved database would occupy a sidebar to the right of the 4-Year grid.
However, I laid out two navigation formats to see which approach users liked most during testing.
After confirming with the Carta dev team that we didn’t have the bandwidth to implement (and maintain) absolute coverage of the requirement-contingencies framework, I decided to strike a balance between “omniscient” guidance and “build-your-own major” flexibility.
While we may not be able to inject every requirement rule into code, we can pre-populate the ReqsBar with the higher-level organization for each degree. For example, a Biology major using the 4-Year Planner would automatically see the 60-Level, Foundations, Lab, and other major-specific categories on the ReqsBar. Also, every Stanford student has to fulfill the same General Education requirements – ah, some standardization!
To fulfill each of the categories within the Skeletal structure, a partial “build-your-own” requirements approach would be necessary. I envisioned that each student would assign classes to fulfill one (or more) of the pre-populated categories at their own discretion, based on their understanding of their degree requirements.
Of course, I didn’t want to leave our users in the dark! Common in 4-Year Plan screenshots was what I called “rule transcription”, wherein users would recite/attach relevant requirement information – occasionally in the form of links – to the planner itself.
Researching analogous UI, building grayscale prototypes based on previous insights, realizing the short-term planning experience.
In order to flesh out the QuarterView, I needed to first analyze the interfaces that students currently use to plan their short-term academic schedules.
Virtually every student uses Stanford’s official SimpleEnroll platform to enroll in (and often times plan) their quarter schedule. For the current quarter in which course enrollment is open, students search classes they're planning to or are considering taking. Students also have the option to “Plan” a class rather than enroll in it.
This is what separates, according to users in our Qualitative research, SimpleEnroll from the other official enrollment tool – enrolled classes show up as “time blocks” on their weekly schedule, giving users an intuitive workflow to build their schedule. Hence, the analogy of playing “Tetris”.
SimpleEnroll provides detailed logistical information to give context to the weekly time-block view upon user interaction. Users can see in more detail the scheduling information of each course within two UI components.
The Sidebar on CartaV1 persists throughout the Carta experience, offering a touchpoint for users to short-term plan regardless of their current stage in the course browsing user flow.
When a user pins a class that they are looking at, that class is automatically added to the pinned classes on the Sidebar for the selected quarter. Within the Planner, users can also see, for each quarter, the classes in those quarters that have been pinned.
Basically, the Sidebar is just showing the same scheduled content as the Planner, but in a different temporal duration.
The Quarter schedule is hidden when there are many classes pinned to that quarter, because it’s beneath those items.
All sections for a pinned class are automatically added to the schedule, so classes with many sections make the schedule incredibly packed.
Since the Sidebar + QuarterView show scheduled content within the same “temporal duration” – one quarter, there are many consistencies threaded through both views by nature of their shared use cases.
I organized classes for a quarter into 2 buckets – Must-Take = “classes that the user NEEDS to take then” and Other = “classes that the user is considering to take then”.
This decision came from insights that students’ #1 priority during long and short-term planning is planning the classes they “need to take” and making sure that they take those “need to take” classes on-time.
Utilizing Carta V1 terminology, students explicitly “plan” courses that are “pinned” to a quarter. Recalling the UX problems of the Carta V1 sidebar and the fact that students often consider (or “pin”) 12 courses for a quarter, it was necessary to make users explicitly choose which courses would show up on the weekly schedule.
Since students are building a quarter that meets pre-defined goals, we find that a critical part of this end goal is the ability to answer, “how does the quarter schedule that I’m building compare to past quarter schedules that I’ve taken?”
The 4-Year Planner and QuarterView features are simply 2 different views – temporal durations – of the same content, inspired by the Apple/Google calendars. A user can navigate from their 4-Year view to the QuarterView to "zoom" into a quarter or vice-versa, depending on their use case in that context.
Since many students (especially undecided freshmen) plan one quarter at a time, it was necessary provide them access to the Saved database and ReqsBar rather than forcing them to toggle to the 4-Year view to access and update that information.
Conducting user tests, synthesizing insights, iterating, ideating, on repeat.
This project is currently in the middle of user testing, so stay tuned to see further updates and eventual the final product!