Rethinking Class Planning
Designing the mobile experience of a class planning tool for 20,000+ BYU-Idaho students
Class registration has historically been confusing and frustrating for students at BYU-Idaho, especially freshmen. I helped create a tool from the ground up that would help simplify the process of choosing and registering for classes for 20,000+ campus students and owned the full mobile experience.
EdTech, B2C
Role
UX Designer
Team
UX Manager, 2 Designers, Engineers
Duration
4 Months
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 also knew some courses filled faster than expected, leaving students to rework their plans and still graduate on time.
Before the tool:
Hard to navigate
Students struggled to find their way through the old registration search.
Planned on paper
So they took notes by hand to keep track of their options.
The Class Schedule Tool was proposed to make planning each semester easier and less stressful. When I joined, stakeholders had already shared what they wanted the tool to do. The design team had interviewed students on campus to understand their problems with the existing system, compared how other universities handle registration, and created and tested very early prototypes.
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 team, so I had to figure out a lot of what to do on my own, even though my manager and other designer were quick to help.
I started from the stakeholder requirements and user requests below, and wrote a How Might We statement to keep us aimed at the overarching problem.
Stakeholder requirements
Ability to plan classes all in one tool
Easy experience so all students can use
Registering for classes is easier
Better indication of course demand through viewing students’ plans sooner
Notifications to let students know of relevant changes
User requests
Display of key class information for quick comparisons
Easier registration process
Less stress and scrambling on registration day
Help to plan a more balanced schedule
How might we
What will happen when a student’s planned class becomes full?
This question came up in my second week. Students used to build their schedule on registration day, but our tool asked them to plan far ahead, so a planned class could fill up before they registered. I realized that helping users find promising alternate solutions after they had created a plan would make or break the experience, so I brought our UX manager and the other designer together to map every warning and error and how a student could respond.
When a class fills up:
Across the timeline
What could go wrong at each stage, from pre-registration through the add/drop deadline.
Errors, named early
Time conflicts, missing prerequisites and full or filling sections, each flagged with a notification.
A way forward
Waitlists and plan alternatives, so a full class never left a student stuck.
While I kept deepening my understanding of the problem, our team prepared low-fidelity wireframes for usability testing. Across the project, we ran 12 rounds of usability testing, with 120+ tests and interviews in all. Here are the three rounds with the biggest takeaways from the research I conducted.
First round of iteration
At this stage, the other designer and I were building a visual schedule builder page. One of the main concerns behind the new tool was that students couldn’t “see” what their schedule would look like while planning it. Here’s the main feedback we received from students in this round.
Tested in round 1
Tiles looked draggable
Students tried to drag courses onto the calendar, so we added a signifier for clicking.
Fewer features, the right ones
We added a button for courses outside the Grad Plan and removed the unused backup plan.
Credits got missed
Students didn’t notice their planned credits, so we made the count more prominent.
Revised design
A click cue on hover
Hovering over a course in the list shows a pointer and an arrow that signal clicking.
Add courses, no backup plan
An “Add Course to List” button brings in courses outside the Grad Plan, and the backup plan is gone.
Credits in the header
Planned credits now sit in the header, with a label like “Part Time Student” beside them.
Second round of iteration
This stage took the longest, because after planning, students had two next steps: resolve any warnings, like a planned section filling up, and register on their registration date. While the other designer kept working on the schedule builder, I focused here, exploring summary page layouts that would walk students through both. The feedback below came from testing several of these layouts over time, shown on one for simplicity.
Tested in round 2
Planning isn’t registering
Many students skipped the next-step message and thought they’d already registered.
Too much on screen
Students ignored the tabs and hesitated at cluttered tiles, so we merged pages and simplified.
Full classes stalled students
When a planned class filled up, the vague “Review” left students unsure what to do.
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. Testing showed me, round by round, why each earlier layout fell short, which led me to create the final solution below. With next steps on the schedule builder itself, students could see there was more to do after planning, and the confusion about registering seemed to fade.
Final design
Registration status up top
“Registered Credits” sits beside planned credits, next to a “My Registration” button.
One page, no tabs
The summary tabs are gone, and waitlist warnings show right on the schedule builder.
A clear next step
A full section offers “Join Waitlist”, with other open sections listed below it.
Third round of iteration
The last piece to figure out was getting students started. They could plan their schedule themselves or begin with one auto-generated from their courses.
Tested in round 3
The intro went unread
Students went straight to the buttons, so the calendar itself became the introduction.
“Manually” scared people off
Students wanted to plan themselves but most picked auto-generate, so planning yourself became the default.
One page, not two
Without a schedule to see yet, this screen confused students, so we merged it into planning.
Revised design
The calendar comes first
Students land straight on the weekly calendar, with their course list beside it.
Planning yourself by default
“Auto-Schedule” is now an optional button that opens a short preferences dialog.
One page, no welcome
The welcome screen is gone, and the course list and calendar share one page.
Once the flow was solid, I was tasked with designing the full mobile prototype. The features were the same, but the smaller screen meant rethinking much of the interface.
I studied Outlook, Google Calendar and iPhone’s Calendar to see how mobile calendars differ from desktop. In all three, the calendar is the primary page, and a secondary overlay is used to add items to the calendar, with a hamburger menu for navigation.
Giving students a high-level view of every semester
I also designed the dashboard students land on before they plan. I wanted it to be a quick, high-level read, so the next upcoming semester carries the main call to action, with past and later semesters still in view. Their declared plan from Grad Planner and their track sit at the top, so even newer students know which semesters to plan for. Feedback before handoff led to a few refinements, and it shipped with the beta as designed.
From start to finish:
1. Start on the dashboard
Students see every semester and begin planning the next one.
2. Choose sections
Students compare a course’s sections beside their weekly calendar.
3. Leave with a full schedule
A complete week, with each class ready to register.
BYU-Idaho’s design system evolved throughout this project as we worked to revamp it and flesh out what our team had. One of my major contributions to the team was organizing and standardizing it, and button components and other elements went through major overhauls along the way. The rules for mobile calendars that I established for this project were also added to the design system.
After 4 months on the tool, we were excited to hand it off for development! We’d outsourced the build to a separate company and met with them throughout the project to get their input on our concepts and design decisions. For the handoff, we documented the designs with user stories, and I was responsible for documenting the flows for mobile. The tool went on to launch in beta to 6,000 incoming freshmen before its campus-wide rollout.
The launch
20,000+
Campus students the tool was built for
6,000
Freshmen in the beta launch
↳ How we tested it
12
Rounds of usability testing
120+
Usability tests and user interviews across the project
The biggest lesson here came from the work I let go of. The summary page took longer than anything else I designed, and testing kept showing me it wasn’t working. Moving next steps onto the schedule builder was the turning point of the project, and it taught me to trust what students do over what I’ve already built.
The results made it worth it. The tool launched to 6,000 freshmen and then across campus, and it made registering for classes easier for real students. That’s the kind of impact I want my work to keep having.
