Introduction
In poor shape and needing an overhaul, our previous class request system, called Early Registration, collected continuing students’ registration requests in an outdated interface. Students entered class unique numbers to identify the classes for which they wanted to register. Students stressfully submitted their requests hoping they entered the correct numbers since the application provided no feedback to students. We wanted to better their experiences so it could be less time- and mind- consuming.
What is Early Registration?
Registration for law school can be complicated. Rather than having a first-come, first-served registration system based on completed hours, some law schools have a pre-registration period with some version of a lottery to assign classes to students. At Texas Law, we call it Early Registration.
Phases of Early Registration
- Students submit class requests.
- Classes are awarded by an algorithm.
- Students view the results.
- Awarded results are sent to a main campus system that actually registers the classes for each student.
- Students add/drop classes to refine their schedules using the main campus registration system.
Student requests
Students review the upcoming semester’s class offerings, decide which they want to register for, and enter up to ten classes into a request that is sent to the Student Affairs Office. But wait! It couldn’t possibly be that easy.
Students must also rank their requested classes. An algorithm processes requested classes starting with the first-ranked class. The higher the rank, the more likely you will be awarded that class. Ranking is based on various factors, such as:
- Enrollment limits: If fewer seats are available, students might rank the class higher.
- Reverse-priority classes: Awarded first to students who have fewer completed hours rather than the normal priority of first awarding students closer to graduation.
- Popularity of the class
Class awarding
An algorithm processes all requests to award classes to students. A complex cog in the system, the algorithm serves as the brain of registration.
Awarded results
Students view the classes they were awarded, along with a basic statement about why other class requests weren’t awarded.
Main campus registration
Since the main campus’ Office of the Registrar actually registers students for classes, Texas Law compiles them into a batch process that loads the awarded classes for each student directly into the main campus registration system.
Initial Departmental Requirements
Knowing our Early Registration system needed an extreme overhaul, we met with our Student Affairs Office to discuss their initial requirements. Key takeaways:
- Don’t allow application-based classes, like clinics and internships, to be requested in Early Registration. Once student applications are approved, those classes are registered during an add/drop period.
- Displaying more information like total class seats and historical enrollment numbers that can assist students with ranking their class requests
- Reworking the awarding algorithm, which included fixing bugs with class time conflicts
- More transparency about the Early Registration process
We also encouraged Student Affairs to think of the impossible with the existing system. For example, could students submit a request without entering unique numbers? Crazy, we know.
Initial Student Feedback
To determine key features on which our team could focus, we sent a student survey that asked about pain points students had with the existing Early Registration system. We also asked what an ideal process would be, and we gave them a top task survey to indicate their top five features for a new system. Students also indicated if they’d like to participate further in the research and testing phases.
Three features stood out as being most important to students:
- View classes in a weekly time block grid
- Show enrollment limits for a class
- Ability to designate an alternate class for a first-choice class
A set of five features also seemed to be important:
- Ability to plan different schedules, save them, and return to edit them
- If waitlisted for a course, show your number on the waitlist
- Designate a course as a “favorite”
- Indicate time conflicts between classes
- Display the reason you weren’t registered for a class (e.g., class is full)
Top task survey indicated several features students desired
Emerging Patterns from Student Interviews
Focusing on the features identified from the initial student survey, we interviewed students individually to discuss features in more depth.
We found a common pattern: To prepare for submitting an Early Registration request, students generally did the following steps in this order:
- Reviewed the newly-published class schedule for the upcoming semester
- Examined various details about classes that interested them
- Built a visual weekly time grid to find a suitable class schedule
- Kept class details available for a week or more by
- keeping browser tabs open
- manually copying and pasting details into a document
- hand-writing notes
OMG. This project is massive.
One thing became clear to our team after the student interviews: We were not simply overhauling the Early Registration system. We also needed to create better planning tools in order to streamline and alleviate the overly manual process students had to undergo to decide which classes to request.
Once we understood how students prepared for Early Registration, we divided the project into smaller chunks (several of which have case studies):
Research phase
Planning phase
Request phase
- Ranking and requesting classes
- Algorithm awarding
Results phase
- Viewing awarded results
Cribbing from E-commerce
Our team discussed ways to mimic an online shopping experience for Early Registration:
- Find classes you want to “buy.”
- Put those classes in an online shopping cart.
- Checkout (register).
Finding the classes you want to buy became the research and planning phases, which are documented in other case studies. Once we built those tools, we tested them with students along with ideas for a new Early Registration system.
Student Feedback on Functionality
Students provided feedback and preferences on two ideas for how the Early Registration interface could work.
Option 1: Holding Area
Students could add classes to a holding area on the left side of the screen, then rank them on the right. This option allows students to drag and drop to rank and un-rank classes as needed
Option 2: One list
Students could add classes to the bottom of a ranked list, then drag and drop that class to a rank of their choosing. Once the student exceeds ten ranked classes, added classes would begin appearing below the line denoting the end of their registration request.
Results
The majority of students found the Holding Area option to be the most intuitive.
Alternate Classes
Students indicated they wanted to designate an alternate class if case their top choices weren’t available.
The idea of alternates made sense to a point. If a student ranked their #1 and #2 spots with different sections of the same course, and their #1 spot was awarded, their #2 spot became useless.
We saw two ways of dealing with this situation:
1. Assign a class
Designate a specific alternate class if a top-ranked spot wasn’t awarded.
2. Skip a class
Skip a specific ranked class further down in their request if a class was awarded.
Student feedback
Even though students indicated in the survey that they wanted alternates, our student interviews found that, for the most part, students didn’t see a need for alternates until we described the situation above. And most students preferred designating a specific alternate class to be considered if their #1 spot wasn’t awarded opposed to skipping a class if their #1 spot was awarded.
A feature that didn’t make sense
While discussing the results from student testing with the Student Affairs team, we began to question the logic of even having alternate choices. As the Student Affairs team stated, students have built-in alternates with subsequent ranked spots in their requests.
Since the theory behind alternate choices was either too complicated or simply didn’t make enough sense, and with students not entirely understanding the need for such a feature, our team decided not to implement it. If the idea made more sense in the future, we could flesh it out then.
TL;DR: We scrapped it.
Adding Classes to Rank
In the existing system, students had to enter unique numbers into their request with no feedback if they entered the correct number for the class they wanted. To better this experience and to streamline the entire process, we implemented the following ways to add classes to a request:
- Import a schedule from the Schedule Planner tool.
- Import favorites from the My Favorites tool.
- Add classes from a search feature
Three ways to add classes to an Early Registration request
Being able to have the list of favorite courses that I could add easily to the schedule planner, and then being able drop the schedule planner into the early registration system directly was such a timesaver from my old method (which involved lots of open tabs, a spreadsheet, copy/paste, and my Google Calendar).
3L
Purposeful limitations
We added the following checks to ensure students couldn’t rank a class they couldn’t take:
- Does the student have the required prerequisite?
- Is the student trying to add a first-year-only class?
- Is the class an application-based class, such as an internship?
- Is the class a non-repeatable class the student has already taken?
If any of these conditions returned true, then the class couldn’t be added through planned schedules, favorites, or the search field. We also added help language that described why certain classes weren’t available to add to the ranked request.
Certain classes cannot be added through a planned schedule.
Certain classes cannot be added through My Favorites.
Helpful information about why certain classes cannot be added to a request
Drag-and-Drop Functionality
Using the Sortable.js library allowed us to define multiple draggable regions where classes could be ranked and sorted.
Accessibility with drag and drop
Through additional work, our team made sure dragging to different regions was possible using keyboard navigation. We also provided meaningful feedback about where classes were being grabbed and dropped for users who use screen readers.
Enrollment Limits
One determining factor on how to rank classes is how many seats are available for each class. The smaller the seat limit, the higher a student might rank the class in order to have a better chance of being awarded that class.
The Student Affairs Office was hesitant at first to display the number of total seats for each class because the number of seats can change while students are submitting their requests. The window for registration is so tight that some class details are still being adjusted during that time. Student Affairs understandably didn’t want students to see a total seat count when they submitted their request only to have that count change shortly after.
Working together, we found a compromise: We would display total seat counts with real-time data so students could see the changes immediately. And, since students could edit their request as much as needed during the Early Registration window, students could see if the seat count changed and resubmit their request if they wanted to adjust their rankings.
Total seat count listed for each class along with a link to the help page.
How Often a Class Fills Up
Another determining factor on how to rank classes is how often a class fills up during awarding. This data combined with the number of total seats a class has are the top factors in ranking methodology.
Immediately, our team realized the complexity of relaying this data for student consumption. We had many years of historical data that identified when a student was denied a class because it was full. But how to label and display it?
Originally, we wanted to display this data as some sort of pie chart or other visual indicator. However, the data didn’t seem intuitive enough for a visual indicator.
We moved on to a text-based display. This class filled up X% of the time in the past was our original language, with X being an average of the past 3-5 years of Early Registration data for that class. However, that percentage would be misleading because of how the algorithm processed classes during awarding.
Therefore, we decided to display This class fills up X% of the time since we had data on how many class denials were stamped with “class full” in the database.
It’s odd and complicated, but we needed to ensure the data provided to students was meaningful but also accurate and not misleading.
The language chosen still wasn’t quite right.
While user testing supported the language This class fills up X% of the time, it puzzled students during registration. After we launched the new system and completed one cycle of Early Registration, we sent a survey to students asking about their experiences. The language, while meaningful, was unclear to many students. Therefore, we brainstormed other ways to present this important piece of data.
We could simply rephrase the statement in a better way or we could go in another direction and state that a class fills up [almost never / some of the time / most of the time / almost always].
We presented these ideas to students, and rephrasing the statement won: X% of past requests weren’t awarded because the class was full.
Most recent reworking of the language
Corresponding Classes
Some of our classes have required classes that must be registered together, like a lecture with a workshop. Both of these corresponding classes must be ranked in a student’s registration request; otherwise, neither of the classes will be registered. And here’s a fun catch – some corresponding classes have multiple sections to choose from.
How to have students rank both classes and sections in an uncomplicated way?
Visually
By visually locking corresponding classes together, we force students to select which corresponding sections they wished to register.
Since the awarding algorithm runs through ranked classes sequentially, students can choose a preferred section to try first.
Validation
We added the following checks to ensure students’ requests were submitted accurately:
- An error if the student tried to submit but hadn’t designated a corresponding class yet
- Inability to rank the corresponding class separately
Warnings
One of the most common reasons why a class isn’t awarded is because it had a time conflict with a class that was already awarded. Students and administrators agreed better identification of time conflicts would help students submit more effective class requests.
During our interviews with students, the idea of using iconography to identify time conflicts came up many times.
Do we use a specific icon just for time conflicts? Or do we use one icon for any type of conflict?
Ultimately, we decided to use one warning icon for any conflict or warning that appeared for a ranked class.
We implemented a tooltip to provide details about the warning.
Reworked tooltip after testing: Headings and lists gave users more context and allowed for scanning.
Testing results
We had two issues with our warnings during testing:
- Submitting a request with conflicts
- Not able to see warning icons
Submitting a request with conflicts
Seeing a red warning icon, one user understandably thought he couldn’t submit his request until he resolved all listed conflicts.
Solution: We changed the icon color from red to yellow and added a statement to the tooltip that the request could still be submitted.
Changing the icon color and adding a bolded statement helped users better understand conflicts and warnings.
Inability to see the warning icon
During testing, one user said she wanted the application to tell her when she had a time conflict with her ranked classes. Turns out, our application did have that feature (through warning icons), but she wasn’t able to see it on her smaller laptop screen. Additionally, the scroll indicator we implemented didn’t catch her attention, so she never scrolled to the right.
Horizontal scrolling was an problem to solve.
Solution: We moved the warning icon to the left side of a ranked class and reworked our horizontal scroll indicator.
Seminars
Since seminar classes are awarded before any other ranked class due to specific degree requirements, we needed a way to separate seminars from regular classes in the ranked request.
Our team decided to add a separate drag-and-drop area specifically for seminars. While this seemed to work well during testing, one student showed us that we needed to provide better feedback to the user when attempting to drag a seminar to the incorrect drag-and-drop area.
Submitted and Awarded Views
Providing clear messaging was important for this project since the entire process is often unclear to students.
Submitted view
For the submitted view, students needed to know that they can edit and resubmit their request as much as they wanted before the window closed. We added detailed information about what happens next in the registration cycle.
Students also needed to continue to see real-time seat counts for each class since those counts are updated throughout Early Registration.
Submitted view
Awarded view
For the awarded view, students needed a very understandable visual indicator that they were either awarded a class or not. To mimic their degree audits, we used the green checkmark icon for awarded and a red X icon for not awarded. Any class not awarded also needed a clear statement about why the class was not awarded.
Awarded view
A Very Necessary Help Page
Writing language for a help page is difficult, and our team had a lot of areas to address. Students and admins made it clear that the awarding process was very elusive and unknown to them. We wanted to change that to facilitate less phone calls to our Student Affairs Office after awarding occurred.
In the help page, we addressed:
- Early Registration timeline
- Why clearing registration bars is important
- Total seat data and X% of past requests weren’t awarded because class was full data
- How to add a class from a planned schedule, favorites, or the search field
- Why certain classes may not be available to add to the request
- How to rank classes
- Seminars
- Submitting and editing a request
- Detailing how the awarding process works
- Reviewing awarded results and what each not-awarded statement means
Admin Views
While students are the primary user group for Early Registration, admins also use the system. We collaborated with admins on what they needed to do their work for registration and came up with a number of improvements:
- A sortable list of all classes and the awarding results
- Ability to drill-down to individual classes and individual students
- Ability to send awarded results to main campus for actual registration
- Registration bar reports
- CSV export features
Results
We surveyed students after Early Registration concluded. The feedback was very delightful, as we found several improvements (like a bug with drag-and-drop on small screens) to make the experience better along with excited feedback from students. Overwhelmingly, students felt the new Early Registration application was easy to use and understand.
There was clearly a lot of thought in the organization and it made Early Registration run so smoothly.
3L
Insights
We found interesting data after building all the new registration tools.
- The most favorited class = the most requested class
- 86% of students got their top-ranked class.
Bits of data like these can help course planning in future semesters.
The old system was like a rotary phone; the new system was like an iPhone 13.
3L