Schedule Builder

Overview *

Redesigning the process of using schedule builder, which is UC Davis' official course registration tool, to heighten the user experience.

I ran through a six-week design sprint process to redesign schedule builder, leading the prototyping and A/B testing portion of the project.

Details *

My Role
User Experience Design, Visual Design, User Research, Led prototyping and A/B Testing

Team
Kiara (project mentor), Meghna, Aeon, Kai (all designers)

Tools
Figma, Google forms, Notion, Slack

Duration
Six weeks

Okay, so what's the issue?

Students undergo a time consuming experience with excessive clicking due to the unclear navigation and organization. Many of schedule builder’s features are hidden under tabs or duplicated, leaving users with multiple ways to access a function, such as searching for a course.

This problem mainly affects...
New students such as freshman and transfers students or those looking to make a schedule in a short amount of time.

This is what schedule builder currently looks like. Students are able to access features such as searching for a course in various ways, making it confusing for first time users.

Understanding our audience

Research plan

To approach the redesign of Schedule Builder, our team worked to better understand the needs and concerns of the target audience. Being that Schedule Builder is a central course registration tool for students at UC Davis, our target audience naturally fell to students.

We planned to do a competitive audit but it was difficult as we didn’t have access to course registration programs from other universities. As a team we decided that since our main research goals was to better understand how the platform is utilized a survey would be the next course of action.

Getting Insight

We sent out a survey asking students about how often they utilize Schedule Builder, and asked them to rate how comfortable they are utilizing certain features.

The rating questions were based on a scale of 1-5 (1 being extremely negative, 5 being extremely positive) and here is what they had to say...

2.95/5
Rating using schedule builder for the first time

3.18/5
Rating building schedules without conflicting classes

3.33/5
Rating looking up classes they’re interested in

Interviews

Though the survey was a good way to get insights from our audience, we decided that further research was needed to better understand what students are struggling with. Eight user interviews were conducted, and here are key points that my interviewees mentioned.

Synthesis *

To streamline the findings from interviews and prioritize the main focus areas we used affinity mapping to categorize related responses together.

This was helpful to understand the audience's goals and would lead the remainder of the design process
To further streamline the process, we took what was said and categorized it into visual presentation, convenience, accessibility, integration, features, and other

After categorizing them, as a team, we voted on three features that best encapsulated the user's pain points based on interviews

Key points from affinity mapping pictured above ^

Key points *

Reviewing the votes, they were slightly spread out. To narrow down the focus and ensure that we had enough time, we focused on three points, as they had nearly everyone's vote. However, we didn't disregard the other points that weren't pick, and found a way to incorporate it into the final design.

While each user had a variety of needs and pain points, after categorizing and looking across all our users, we crafted a how might we statement that encapsulated our user’s main goals

“How might we make it easy to build non-time conflicting schedules and make the user experience more interactive and enjoyable?”

Okay, time for ideation

The vision

Everyone diverged and created solution sketches based on features that best hit the pain points of our users. Some things we considered were…

1. Restructuring how our users would look at their courses and schedule on the calendar

2. Making time conflicting courses more obvious to warn users ahead of time

3. Making course details easy to read and minimize the navigation on a page

Developing the vision

From our sketches, we split up to develop different portions of our low-fidelity wireframes. My task was centralized around the main calendar and scheduling portion of the interface. Focusing on how users would edit their schedules and how it would display different types of schedules such as the week, day, and finals view.

Mid Fidelity + Usability testing

Prepping for usability testing

After developing a user flow and wireframes, we developed mid fidelity wireframes. At this stage implementing colors, and a more cohesive design system.

Once completed, we had users run through tasks such as opening the schedule page, editing and saving their schedule, as well as searching for courses, while closely observing how they interacted with the prototype.

Things we looked out for...

How effortless is it to complete the assigned tasks?
How well does our assumed user flow align with our users' approach?

User flow developed for usability testing ^

Insights + A/B Testing *

Based on user testing many had trouble navigating the prototype and most weren't able to complete the tasks given to them. A task given was to edit their schedule, but the wording on the buttons left testers unsure of where to click. With so much uncertainty and confusion, it didn’t feel right to proceed onto hi-fidelity, so we decided to conduct A/B testing to get more insights.

I led this portion by setting up the testing file, laying out the sections that needed to be tested, and writing the script to test users. Through testing I was able to identify areas that improved usability and went forward with those design choices in the final solution.