Redesigning Occidental College’s Registration Process
Introduction:
Ah, the registration process.
It is an essential task for every student but sometimes an equally frustrating experiences for the average student at Occidental College.
Previously, I conducted a critique of Occidental College’s registration process. This critique revealed many faulty aspects of the process that urged for redesigning a user’s experience with registering for courses for a certain semester. In addition, the critique highlighted many needs of an Oxy student when registering for classes.
When considering redesigning the Oxy student’s registration process, my design partner and I focused on one particular need. From there, we created an experience that tends to this focused need of an Oxy student through the registration process.
We decided on one particular need of Oxy students:
organizing one’s class schedule for the semester in conjunction with other commitments (i.e. work, extracurriculars)
A college student’s schedule is not limited to the registration of classes. Everyone’s schedule is unique, which urges for different circumstances such as making sure to not schedule classes before 11am, or making sure that classes scheduled are adaptable to work shifts.
After interviewing students, many of them opted the use of several sites in combination with Oxy’s registration tools like Course Counts. This prompted that Occidental College’s registration process online was absent of features that Oxy student’s looked for in other tools such as Google Sheets/Excel and Calendar apps.
People use these sites to provide helpful transparency of organizing a schedule that is compatible to what a student wants to accomplish for a semester. Visualizing one’s schedule through the individual cells of Excel and calendar apps enable a user to make sense of what classes work and what don’t so as to mitigate restrictions that may occur when registering for classes within a narrow time slot. In other words, we wanted to create an organizing experience that allows users to see what their schedule would be to increase one’s readiness and confidence when registering for courses during their time slot, which is contingent on registering for classes as fast as possible before other students register for similar classes.
Design Process
My partner and I aimed to work towards a design that allowed students to better organize their schedule when picking courses for a semester. The task of picking courses is involved with many decisions influenced by different reasons. This includes picking courses out of interest, fulfilling major requirements, and fulfilling core requirements for Occidental College. These parts of the registration process prompted my partner and I to specifically design functions that allow students to have the information they need to register for courses.
These informational needs include:
- Checking major requirements that need to be completed based on past academic records
- Checking core requirements that need to be completed based on past academic records
- Registering for courses based on specific preferences such as time, professor, subject, and semester
- More information about the certain class’s content
- Prerequisites and/or additional requirements for registering a class
- The time constrains of other classes that are needed for a semester (in order to register additional courses for reaching the required minimum of 16.00 units a semester)
The path towards identifying these informational needs took the form of brainstorming certain scenarios that highlight tools that Oxy students may need for registration. Our targeted users for our design are Oxy students registering for courses. However, every Oxy student is different. Different students like classes at different times, have jobs, and are interested in different subjects:
We settled on two designs. These rough sketches show the overall layout that we were thinking of:
Remember that the need that we focused on was:
“clearly organizing one’s class schedule for the semester in conjunction with other commitments (i.e. work, extracurriculars)”
We decided to implement a schedule visualizer for the process of picking courses that are available during a semester.
This schedule visualizer will essentially organize obligations into a calendar style. People can better remember things through multi-sensory aspects. By having the visual tool of organizing one’s schedule, users can understand possible schedule conflicts and the amount of time they would have out of an average day (i.e. visualizing how close together classes are).
The first design included having a schedule visualizer and the list of possible courses to register from as part of the same screen:
First Design
We thought of this split-screen design in order to condense all of the components that we were thinking of on one screen. Instead of prompting users to access other sites to compensate for absent tools from Oxy sites, we wanted to supply users with more tools on one screen of two core functions. We knew that the core part of our redesign was supplying users with a schedule visualizer.
The question was how we were going to implement the schedule visualizer in accordance with the selection of courses that students go through through Occidental College’s Course Counts site. Since the process of registering required the collaborative effort of checking what courses a user was interested in taking in accordance to their personal requirements (i.e. major requirements, core requirements), we wanted to make the task of choosing courses and the task of putting together a schedule (visually) linked to each other.
Functions of Design 1
Essentially, when a user would check on the box under ‘Add to Schedule?’ for a course, the design would add that particular class to the schedule visualizer on the bottom of the screen.
- Users would be able to search for particular courses by choosing from the filters above the course list.
- On the bottom right side of the screen, the ‘Events’ box contains other events that a student would want to visualize on their schedule.
- If they are thinking of joining a club or working on campus, they would be able to visualize these obligations with the classes that they are planning to register for through pressing the ellipses in the ‘Events’ box.
- The ellipses near the events would signify the affordance of pressing on them to edit that certain event by time or deleting it.
The second design included having the schedule visualizer and the list of possible courses to register from as part of separate screens accessible from different tabs:
Second Design
Functions of Design 2
The second design essentially shared the same idea. We wanted to have the schedule visualizer work closely with the choosing of classes that are available for the semester. It also had additional functions:
- Accessing both functionalities by tab was due to the intended effect of having a clear distinction between two tasks by grouping them by screen.
- Users can access more information about a course in the schedule visualizer tab by pressing on the ‘+’ button of a certain course
- The red box near a certain course will show up when a conflict appears. If a user hovers over the red or presses on the ‘!’, it shows more information about what events are conflicting. Red is a color that naturally represents caution, which is why we chose it to warn users that a conflict exists (which will constrain them from registering for both classes in a conflict).
User Testing
The next decision was to decide on which design to pursue. We chose which one to pursue by conducting user testing on both designs.
We did this by asking several people of different majors and obligations to navigate our designs. For example, some of our users were physics majors, computer science majors, and economics majors.
We asked our users to use our design to do several different tasks:
- Register for a class
- Add that class to the schedule visualizer
- Check for personal requirements (i.e. core requirements and major requirements)
- Identify if their schedule shows a conflict or not
We made sure to briefly tell them the overview of each design. But, we were sure not to explain too many details. The point of this user testing was to see if our users could navigate the page themselves, relying on the signifiers that we provided.
Overall, our users appreciated the additional layouts of our designs. In comparison to their current relationship with Oxy’s registration sites, our users liked how they had more tools to aid them in visualizing their semester.
The main problems that rose up included:
- The buttons and text were too small
- Make the conflict info more noticeable
- Making subtitles more noticeable
When asked about which design our users preferred, they said:
“Design 2 is much prettier but I like the tools of Design 1".
We took this comment to heart, and asked about highlights of each design. For Design 1, users stated that they liked how they could add additional obligations to the schedule visualizer.
After asking more users, we found that a majority preferred Design 2. The primary reason for this was that they enjoyed the “cleanliness” of Design 2. They found Design 1 to be more “overwhelming” due to how condensed it was in comparison to Design 2.
Considering the attention of our users, we understood that humans could focus on tasks better when the experience is less cluttered. In addition, the tabs’ would implement the idea of progressive disclosure so as not to overwhelm our users.
From here, we started making new iterations of our design.
Improvements towards Final Design
Below, you can view our next iteration of Design 2, our selected design to be our final design.
The tab, ‘Course Counts’ is in reference to the actual Course Counts site for Oxy students.
We chose the filters below according to the certain aspects of a class that a student looks for. We arranged these buttons in an order of what we thought to be the most important. First, the semester selection is vital to starting the process of choosing courses for the semester. Then, subject. Subject is the next most vital subcategory of searching for a particular course. How do you know which courses to register for? You look for the subject that that course pertains too first, of course! This way, students can scan their personalized features from most important to least important from the standard left-to-right direction of reading.
We added the “Hello, ______.” to incorporate a personalized touch when picking classes. It seems like such a mechanical task sometimes, so we wanted the process to feel more uniquely tied to the student.
In comparison to our design version above, we bolded some titles, made the text bigger, and highlighted the course in blue to offer a clear signifier of the affordance of clicking on the course title to find more info on the course (such as a hyperlink, which I think our users are familiar with).
As you can see, we grouped some aspects of the course listings to take advantage of the Law of Proximity. We thought that course and title went hand in hand, acting as synonymous labels of a course. Furthermore, we grouped the CRN, Units, Instructor, Meeting Times, and Core aspects of the course into one section because they signify specific details of the course. To add, we aimed to group the statistics of how many spots are available to enroll in, reserve, or waitlist for a class because they all relate to the similar cognitive task of figuring out if there is space for one to register for the course.
We used the checkboxes for the last column of ‘Add to Schedule Visualizer?” in order to allow users to select multiple classes to add to their schedule visualizer. When no classes are selected, the ‘Add to Schedule Visualizer’ will gray out so as to show a visual constraint that the user cannot add to the schedule visualizer because they haven’t picked any classes.
Below is the schedule visualizer tab of our final design layout. As you can see, we made the ‘+’ buttons bigger, a major suggestion that our users told us to implement.
When a user clicks on the underlined “!” of the red box, they can find more information of what classes/events conflict.
You can see that we also added the ‘Courses Selected’ box on the right side. This was due to the fact that our users enjoyed that particular feature in Design 1. In addition to visualizing their courses for the semester, users can add other obligations to their schedule. The green boxes represent the courses that are currently portrayed on the visualizer. When these courses are deselected, they are taken out of the visualizer and appear gray. In addition, we added the error message on the bottom right to add multi-modal feedback. We wanted to make sure as to not clutter the schedule visualizer. So, the static error message on the bottom right could provide more information on the conflicts without needing the user input of clicking on the red conflict box. By seeing the error twice — once in the visualizer and once on the side — it represents more caution to the user to fix the problem. This directly tends to our choice to tackle the need of organizing a sound schedule that mitigates possible conflicts through visualization. The ellipses on the right side signify a function of editing the box of possible obligations to add or delete an extracurricular activity, work, or a course.
From here, we really liked our design. When we asked our users to use our design, we also asked how they would feel about having the option to view their personal requirements for the semester. Most, if not, all of them agreed that this would be a very useful tool. This stemmed from their frustration that they often had to go the extra step to access their academic records in myOxy to find there core requirements AND they had to access oxy.edu to find their major’s specific requirements. We wanted to make this part of selecting courses for the semester easier.
On to the next iteration!
Iteration of New Tab
From our first iteration, you may have noticed that we removed the hamburger menu. Initially, we wanted the hamburger menu to present a side menu that showed the personal requirements of the user (i.e. core, major). However, this functionality deemed unnecessary to our users when asked about pressing it instead of the tabs. So, we thought it would be clearer to supply the information of personal requirements as a tab instead — creating a more fluid conceptual map. In retrospect, it would be confusing to have multiple buttons signifying visiting different “pages”. So, we aimed to use tabs to avoid this confusion.
As you can see, it is a simple layout. With one side dedicated to Core Requirements and one side dedicated to Major Requirements, the user can simply toggle between tabs to check which courses they need to be searching for. By having all of this information in one space, users can think of important courses to register for on this one screen. We made sure to utilize bolded text to create a hierarchy of categories.
The Final Iteration Design
And alas, we have reached our final iteration. After asking users to navigate our design once more, we received good feedback. They appreciated the personal requirements tool, but expected some parts of the design to be more clickable. For example, they expected to learn more about the course by pressing on the whole row on the course tab.
By taking the user’s feedback into consideration, we suggested that our design to show a signifier of clicking on any area of a class in the visualizer to open more info about that class.
We changed “Courses Selected” into “Events Selected” on the right hand side to provide more clarity on what can be added. We want our users to understand that they can not only visualize their courses for the semester but other events they may have such as extracurricular activities.
We did think of adding more days to this visualizer, but decided against it, solely sticking to our focus of designing an experience for organizing a school week.
In our final design, we also decided to improve the spacing of our ‘Courses’ tab. After suggestions from our users, we grouped together these sections more clearly. The middle section of specific details of a particular course seemed to mesh with the right section of available seats for a certain course. We made this grouping more obvious, so that users don’t mix up similar looking characters and get distracted from calculating if there is space in a class for them.
As you can see, we did not change much to the ‘personal requirements’ tab. A user did say that we needed to be careful of how to visualize what requirements are needed for a major. Some majors have requirements that could be fulfilled by a list of cross-listed courses and optional courses. But remembering that we were designing for the need of organizing a school week schedule, we made sure to not dive too deep on this feature. However, I will make note of this for future iterations of this design.
Our Final Product
Although our final iteration of the design is provided above, I have also provided a visual of what our design adapts to under certain circumstances.
In this final product, we did apply one last change. We implemented the ‘Search’ boxes of ‘Go’ and ‘Clear’ to provide a visual form of confirmation for users when searching for courses. This will allow users to know that their preferences will be applied to the course listing.
A user has not chosen any courses to add. This dulled out version of the “Add to Schedule Visualizer” button constrains the user from pressing on the button, prompting them to check on a box to use that feature.
A user has pressed on a course to look at more information. We made sure to make this function a drop down box to mitigate the frustration of moving to a new page for course information.
A user has pressed on the underlined exclamation point to view more conflicts. In addition, the switch in red on the middle class conflict show that a user can toggle between classes in a conflict.
We added this functionality, because according to our users, they felt a disconnect with the red conflict box. They wanted to see what class it was in addition to the conflict. We created this functionality of hiding/showing what classes are making the conflict to allow users to toggle between two classes of a conflict. If a user is making a hard decision between two classes that make a conflict, they can use this toggling feature to visualize what their schedule would look like with either one.
Conclusion and Future Suggestions
During this process, I learned a lot about the iteration and user testing process. Listening to the users becomes more beneficial than I thought them so. After rethinking our design in conjunction with our user’s needs and suggestions, I could see more connections unravel. I became more understanding of what a naive user would think of our design and make of our buttons. I learned that the key component is visible transparency. If a user can look at a button and deduce to what it controls on the screen, it is a victory in creating an accurate conceptual model of a user’s experience.
For future designs, I would refine the personal requirements tab. When considering which design to settle with, my partner and I debated on designing a visualizer for a semester or for a student’s four year plan. If I were to further design this experience, I would expand the interface to tend to a student’s process of creating a four year plan. This would create a greater emphasis and provide more options for a user to experiment with different courses that could affect their four year plan. For example, I would design upon contingencies that exist when considering major requirements. Many classes are overlapping and different electives can count for a major depending on the student’s choosing. I would want to further design the final interface to tend to this need of users to experiment with possible second majors, minors, and primary majors. This way, they could also utilize the personal requirements tab on its own. It doesn’t necessarily have to be tied to checking courses to register for from the ‘Courses’ tab. It would provide an informational space for students considering adding to their course load within their plan to graduate on time.
