Rethinking Class Planning
Registering for classes made easy
Class registration has historically been confusing and frustrating for students at BYU-Idaho, especially freshmen. We created a tool from the ground up that would help simplify the process of choosing and registering for classes.
Project Type
Education Software
Role
UX Designer
Team
2 Designers, Senior Designer, UX Manager, Developers
Duration
4 Months
The Problem
BYU-Idaho’s registration system is outdated and difficult to navigate. Freshmen don’t know how to register and often need to ask for assistance. Most students find it daunting to devise a well-balanced schedule between all their options. The most proactive students write on paper the class sections they have in mind before registering to see how all their options work together.
Stakeholders are aware of these issues. They are also aware that there is sometimes more demand for a course than was anticipated, causing all sections to fill up and some students to be left out. This causes students to stress as they figure out how to adapt their plans and graduate on time.
To better serve 20,000 on-campus students at BYU-Idaho, the Class Schedule Tool was proposed to help students plan their classes each semester with greater ease and reduced stress.
Discover
Reviewing Existing Work
When I joined the project, stakeholders had already shared what they wanted the tool to do. The design team also conducted ethnographic interviews with students on campus to understand the main problems they were facing with the existing system. Competitive research was done to see how other university registration systems and processes compare.
Subsequently, very early ideation and prototypes were created and tested.
Define
Taking Initiative
My task after joining the team was to continue to develop the prototype through iteration. One challenge that I encountered was that two of the three designers who had been working on the project had just left the company, so I had to figure out a lot of what to do on my own, even though my coworker and manager were quick to help.
I began by seeking to understand the stakeholder requirements and user wants. With these in mind throughout the project, I was able to ensure that designs fit within project goals. Additionally, my coworker and I devised a How Might We statement to stretch us to solve the overarching problem.
How might we make class planning and registration easier for students, so that they can build more balanced schedules for greater success?
What will happen when a student's planned class becomes full?
This question arose during my second week on the project, and it turned out to be important to answer if we were to solve one of the main pain points in the new journey. (Previously, most students figured out their schedule on registration day or shortly before, but because our new tool asks users to plan far in advance, this could become a significant issue.) I realized that helping users find promising alternate solutions after they had created a plan would make or break the user’s experience using this tool.
I created a flow to map out how I saw the student’s options for responding to the various warnings or errors the system might give them.
Design
Improving the Experience through Iteration
While I continued to solidify my understanding of the problem, our team worked on prepping the next low-fidelity wireframe for usability testing. The team conducted 12 rounds of usability testing and 60+ tests throughout the project. For this case study, I will only show 3 design iterations with the biggest takeaways from the research I conducted.
First Round of Iteration
At this stage of the design process, my coworker and I were working on creating a visual schedule builder page for students. One of the main usability concerns that brought about this new tool was the inability to “see” what the student’s schedules would look like while planning their schedule.
Here is the main feedback we received from students during this round of testing.
After receiving this feedback, my fellow designer and I took the suggestions we received to improve the design. The overall feedback showed that users needed more functionality on this page like adding additional classes, but also didn't need other functionality like the backup plan. We also added the functionality to "auto-schedule" which was only available on another page (more on this to come).
Second Round of Iteration
This stage took the longest in the design process. As mentioned previously, major usability issues could arise between the time students initially planned their schedules and when their registration time arrived. If one of their planned class sections filled up before their registration date, this would cause great stress to students if the tool did not notify them and help them find an alternate class that worked for their schedule.
After students had resolved any warnings that might arise, they also needed to register for their planned classes on their registration date. This stage of the experience focused on helping users both resolve warnings and register for their classes—important next steps in the process.
Because of the importance of helping students complete these next steps, I focused heavily on this stage of the experience while my fellow designer continued to work on the visual schedule builder page.
I explored many layouts, which can be seen in the following image. These layouts served the dual function of helping users resolve warnings and register for their classes on a summary page that would tell them their next steps.
I will demonstrate user feedback on one of these for simplicity though this feedback was received cumulatively between the various layouts while testing at different times.
Abandoning the Summary Page
Ultimately, what made the most sense to users was not displaying the next steps on a separate page, but rather including visual indicators for these on the visual schedule builder page. User feedback enabled me to understand incrementally why the previous layouts were unsuccessful, which led me to create the following final solution.
By making the warnings and summary apparent on the visual schedule builder page itself, it was much easier for users to comprehend that there was more to do. Many were operating under the incorrect assumption that the system would register for them after they had planned their classes, which was not possible with the technological constraints. After moving these steps to the visual schedule builder page, confusion seemed to dissipate.
Third Round of Iteration
A third phase that needed to be designed was the portion that helped the user get started in planning their schedule. It outlined two main options: planning the schedule themselves or starting with an auto-generated schedule that took their desired courses into account.
This was the feedback we received:
After receiving this feedback, my fellow designer and I took the suggestions we received to improve the design. Below is the final for this iteration.
Designing for Mobile
Once the team felt confident that the overall flow was solidified, and only minor changes were needed, I was tasked with designing the full prototype for mobile. Where the functionality was the same, the interface, in many cases, needed to be thought about in new ways because of space constraints on smaller mobile screens.
I looked at other calendar tools for mobile as a reference to see how they differed from calendar tools for desktop. Main references included Microsoft Outlook, Google Calendar, and iPhone’s Calendar. The key distinction in mobile for all these tools is that the calendar is the primary page, and a secondary overlay is used to add items to the calendar. Additionally, a hamburger menu is used for navigation.
Design System
It should be noted that BYU-Idaho’s design system evolved throughout this project as we worked to revamp and further flesh out what our team had. Button components underwent major overhauls as did other elements. The rules for mobile calendars that I established for this project were also added to the design system.
Handoff to Engineers
After our team had worked on the tool for 4 months, we were excited to hand it off for development! We outsourced the development to a separate company and had several meetings with them throughout the project to get their input on our overall concepts and design decisions. In preparation for the final handoff, we documented the designs with user stories, and I was responsible for documenting the flows for mobile.
Final Thoughts
This project was an incredible learning opportunity. It was my intro to working on the UX team at BYU-Idaho and the first time my work had such a great reach—20,000 users. I learned how to better work within stakeholder needs and technological restraints while focusing on the user’s needs throughout the project.
Even though I joined the team mid-project and had to go back periodically to understand the goals and previous work, I owned it by jumping in and getting to work. I solidified my understanding of the UX process while working on a tool that would make a difference for users. This was possible through iterative design that ensured the interface was the most logical and intuitive for users.