Wellesley College Registration Project

course scheduler picture

This project was developed in the fall of 2019 under the guidance of Professor Catherine Delcourt in the course CS 220: Human Computer Interaction. Wellesley College is currently using the results of our findings along with related research to improve their course registration system.

The goal of this project was to produce a working prototype in the form of a course scheduler that would prioritze the needs of Wellesley College students who schedule classes around other commitments, such as work hours or athletic practices.

A summary of our team's process can be found below. It takes you through the entire user design process, including research and usability reports, as well as stages of prototyping. My main roles within the team was collaborating on all of the initial research, ideation, and interviews, as well as acting as the developer on our team by coding both prototypes using HTML, JavaScript, and CSS.


We first discussed different types of users at at Wellesley who we thought had unique challenges that would benefit from a revised course scheduler design. By designing for a smaller group, we found that the larger Wellesley College community as a whole would benefit from these changes as well. We determined initial user groups we were interested in further pursuing as our main focus for our target design demographic.

  1. Student Athletes
  2. Interdisciplinary majors
  3. First years
  4. Students who work


The goal of our initial user interviews was to find out what students from different segments of the student population need from a registration process. Different categories of questions were asked to parse the most helpful information from interview candidate, listed below.

  • What is your class year?
  • What is your major(s)/minor?
  • What are you involved in on campus?
  • How much time outside of class do you spend on extracurricular activities?
  • How does your involvement in your activities affect your registration process? I.e. are there certain class times that you cannot make because of your involvement in the activity?
  • Has there ever been a time when the registration process forced you to take a class that conflicted with your other activities?
  • How many times have you registered for classes at Wellesley College?
  • How stressful do you find the past registration process? (i.e. via Banner website) process?
  • What do you like about the Banner registration process?
  • What do you dislike about the Banner registration process?
  • What is your biggest concern during registration period?
  • What has been your strategy when registering for classes in the past? Did you plan your schedule around ONE class that you absolutely needed to get into, or did you plan your optimal four class schedule?
  • Was this strategy a result of the way that the Banner system was set up, or your own personal preferences?
  • What is your ideal strategy-- would you rather build your schedule around one specific class or sacrifice that one class for an optimal four class schedule?
  • What do you dislike about the banner registration process?
  • What is one thing that you would like to see improve in the registration process?


Former registration system (referenced in interviews):

banner photo

Main finds: Student athletes often have strict schedules that prevent them from taking classes during certain practice time periods, and often registration falls during practice times. Finds current registration process unintuitive and difficult for their goal of planning around an optimal 4 class schedule, and suggested possible changes.

athlete empathy map

Full interview:

Main finds: Found the Workday registration to be very stressful, complicated, and confusing. Tried to plan around an optimal 4 class schedule rather than one class, as low priority in the registration rank means less chance of getting into classes, and course browser and syllabi should be clearly displayed on the same platform.

first years empathy map

Full interview:

Main finds: Thinks registration process is "archaic" and unecessarily difficult on the user's end. Tries to plan classes around optimal times if possible. Would like to see unfulfilled degree requirements integrated into the course browser for more ease in choosing classes.

interdiscipline major empathy map

Full interview:

Main finds: Found registration process to be very difficult and stressful, and makes it harder to get into classes. Would sacrifice necessary classes for a more optimal 4 class schedule. Would like to visually see their schedule when registering.

Full interview:


One of the primary concerns among all of the interviewees is the inability to be updated in real time as to how many students are in each class, and which classes are being filled up. This was made harder by the registration process having bad learnability by being difficult and unintuitive to figure out quickly. This problem affects students who are trying to get into a class that is highly in demand; in particular, older students who have less time on campus and need particular classes to graduate- such as the interdisciplinary major. This problem is also highly present in students who have very busy schedules, with little flexibility, such as student athletes or students who need to work jobs There are also concerns that the waitlist, course browser and registration process are not funnelled through the same program. The majority of the interviewees plan their schedule around four classes and try to optimize their schedule while still registering for four classes.

Thus, some guidelines that we will adhere to in the designing process is keeping in mind the unique issues that our target market is experiencing. We will design with the understanding that our users plan their schedule around four classes that maximize their potential and needs, rather than just one specific class that they need to graduate. We will also recognize that information being readily available and easily accessible to students who are registering is especially important. There needs to be real time updates informing the students what classes are filling up as the registration window is open. Additionally, the design must be visually organized and easy for the user to understand use quickly.

Personas and user scenarios

Of the user groups we studied, we felt students with jobs were most representative of the majority of students and whose concerns aligned with many other groups of students. Thus, designing for them would benefit all students. To do this we determined three more subsets of students with jobs to interview and create personas for, asking the following questions to gain more perspective about each particular user group:

  1. How many hours a week do you work?
  2. What time of the day do you work?
  3. How flexible are your hours?
  4. Do you work around your school schedule or do you form your schedule around work or when you think you will work?
  5. Have you ever had an issue with registration that made you rearrange your work schedule?
  6. What changes in the course browser would make your experience smoother?

Persona scenario: ranking times of day

Molly has worked at Bruegger’s Bagels since her first year at Wellesley. She knows that she needs to work at least two shifts a week where one shift is on a weekend and one shift is on a weekday. She works five hour shifts, so she would like to have multiple days with the same five hour block of time where she has no class, in order to either work at Brugger’s or to do her homework during the week. She uses her course registration web application schedule to rank times of the day in terms of her availability. She is able to rank and color code the times of the day that she is most available and willing to take classes, then she is able to rank the times of day when she is available to take classes but it would be less ideal, and finally, she is able to indicate times of the day when she is completely unavailable to take classes. The highest availability is colored green, the middle level availability is colored yellow and the unavailable times are colored red. Molly uses yellow for the chunks of time that surround her shift during the week, because she does not want to be running from class to work, however, if she has to do that, she will. She uses red during the times when she is working so that she will not schedule herself for classes when she is working.


Persona scenario: planning work & school schedule

Sophie has had an on-campus job working at the copy center since her first year and works twice a week here. Her hours are slightly flexible in that she is scheduled for work on days when she is not in class or in between classes, and she has about two weeks to finalize her schedule until her work hours are set. She knows that she likes to block off long hours of her weekdays to be able to work at this job, usually 4-5 hours on two days a week, so she can be scheduled for these hours. She usually uses her Google Calendar to plan around these work hours, but with the course registration app she can add her preferred work schedule into the registration schedule so she can see what times conflict with her preferred work schedule. She has the option to filter out classes from the course browser that conflict with these times where she’d like to be working. This way, she is able to schedule her time around her work schedule by seeing only what classes she would be able to take within certain time frames. This way, she can see if the classes she needs to be taking conflict with her work schedule and can then look into switching her work schedule to be able to take these classes. She can also see if her classes cut too close to her work hours and try to avoid that as well.

Persona scenario: generating backup options/repository of potential schedules

Rachel has two different jobs that both provide some level of flexibility with scheduling their work hours, however, they need to make sure that the classes they choose fit together to give them an optimal schedule. They know that they need to have at least one day when they don’t have classes, and two more days that require them to have a 4 hour block for free time in the early afternoon. As a result, they are not extremely concerned with getting into specific classes, instead more focused on specific class times. They use a Google Docs page to keep a list of classes they like for each specific time block they are interested in, along with the CRN codes for those classes. The CRN codes and titles of classes are colour coded according to their meeting time. They use their Google Calendar to schedule in blocks of their work hours and potential class meeting times that would complement their work schedule. During course registration, they try to get into their top 4 classes first, but if they don’t get into one, they reference their backup list for potential classes in that specific time block.

Preliminary interface designs based off initial user research

Interface design #1
Interface design #2

Task Analysis Hierarchies

Plan work and school schedule around each other
Generate backup options
Rank availability

Design direction

We chose to go with a hybrid of the two preliminary designs we had. The direction we’re headed with our design involves a calendar which takes up most of the screen, and a toolkit on the left side of the screen which gives the user options to add blocks of time (for both free and busy blocks) and also toggle between saved schedules and classes. Users have the option to create a list of classes that they can toggle on and off individually to create different schedules. Blocks of time on the calendar are color coded according to availability.

Note: I advised my team to change the red/green/yellow color scheme to increase accessibility for those who may be color-blind, however these changes are not reflected in this prototype.

A video run-through of our Invision prototype (linked) .

Risky interactions to look out for

  1. “Add block” button: The “add block” button is a potentially risky interaction. This feature will be used frequently, as the user is inputting their blocks of free time and open time. If this element is glitchy, it will affect the usability of the system because the user will not be able to properly see where their chunks of free time is when they are creating their academic schedule. In the most extreme cases, could cause the user to schedule classes during times when they are actually not free. However, even in the less extreme, it would be a nuisance for the user to have to navigate back and forth between a personal calendar and the registration calendar.

  2. "Add class" button: The “add class” button is also a risky interaction because the entire purpose of the system relies on this button working properly. If the “add class” button does not work properly, or the system does not intuitively guide the user into using it correctly, they are unable to then the user will not be able to create academic schedules, and therefore, will not be able to register for classes.

Prototype User Testing Summary

  1. Tester 1: Tester said they probably wouldn’t use the priority ranking but was glad it was an option for those who would benefit from the visual color difference. In the next iteration I would maybe make the “prioritize” portion an option that you would click on that would then lead you to a sub-menu that you could then rank as low, medium, or high. When asked on the notecard to “add a class to your schedule” the tester successfully completed the task and said the interface gave her enough information on where to go on the main page, then when she hit “add class” the pop-up menu appeared and she picked “add class” where the theoretical class then appeared in the schedule.

  2. Tester 2: At first, the tester didn’t understand the use of the colors, but then once they were further explained she said she liked them. The tester also said she didn’t really plan her work schedule while looking for and registering for classes but planned academics first, so she wouldn’t really use the color ranking for that purpose (balancing work/class schedule). However, for recurring commitments that some user groups have, like athletes’ practices, she said this could be useful for them and this could be a good feature. She also really liked the idea of saving multiple schedules and said this would be useful in planning and having backups, but she said she wanted more information (like class times) to be on the side of the screen.

  3. Tester 3: The tester was confused about what the priority times meant, and how that would factor in with classes in her saved schedule (would classes be filtered?). She also thought having users pick colors would be a good option, though it wasn’t shown in the prototype. She also thought that since this registration program was primarily about scheduling classes that finding the classes should be first on the side bar rather than scheduling blocks of time. She also thought maybe having different colors for different classes may be a good idea. She said she liked the idea of being able to see your other commitments on the scheduler itself, and said that she also doesn’t know her work hours that far in advance so having it be shown as “blocks of time” was better than projected work schedule.

Link to prototype 1.0

Prototype documentation write-up

Description of changes made from low-fidelity prototype

After a design review, we revised our prototype and aesthetic choices to reflect the recommendations we received to make our interface more streamlined and sleek.

  1. Color pallete: We changed the color pallette to reflect Wellesley College's colors, a deep navy blue against a white background, to adhere to Wellesley's visual identity design branding guidelines, which may be referenced here. The classes in the schedule are all the same color, but now have the name of the class (course number and course title) in the correct time slots, which is nested in a calendar that includes hour marks, and only includes Monday-Friday, as those are the days that classes are offered.

  2. Font: The font has also changed for increased accessability. Font color is black instead of a dark grey to increase contrast and heighten readability. Whitespace was increased to create a calmer interface that is less crowded and overwhelming.

  3. Sidebar: We rearranged the order of the sidebar in the most current version of our prototype. In our InVision prototype, the sidebar was ordered: add block of time button, list of classes, add class button, save schedule button, then the list of saved schedules. In the 1.0 prototype, we changed the order and created more dropdown buttons to de-clutter the sidebar and add more whitespace. The new order is: My Schedules button, the list of classes with a toggle button next to them, an Add dropdown button (which includes a classes option that takes the user to the course browser, and an add block of time button that will ask the user to input a time block of their preferred preference) and a save schedule dropdown button that the user can actually name and then appears in the “My Schedules” dropdown button.

While some stylistic choices have changed, our goal has not - to allow users to plan their registration schedules around prioritized blocks of time. At this point in the prototype, we were not able to color-code the prioritized blocks of time, so they are all the same color.This will be further explored in our 2.0 prototype.

Usability Test Protocol

We tested three users on the usability of our prototype to gain feedback on if the system is intuitive, easy to learn and understand, and useful.

  1. Warm-up. Brief the users on the general goal of your system and any background information about the domain that may be needed by your test users to understand it. Then ask them a few warm-up questions to learn about their relevant background.

  2. Goal:

    To allow users to plan their registration schedules around prioritized blocks of time. You are someone who fits our designated persona of who would be a target student for this interface.


    • Do you have a job while you are a student at Wellesley College? Give a description.

    • How does your job affect what courses you wish to take (i.e. night classes, long form classes like labs or studio art classes)?

    • Does having the ability to block times that you wish to be free (to work, to do homework, to relax, etc.) help in conceptualizing your ideal schedule?

  3. System description. Explain the purpose of your system and any technical intricacies about the prototype. It should not describe how to use the interface itself.

    The purpose of our system is to allow you to build your schedule around preconceived blocks of free and unavailable times. For example, if you know that you work shifts on Tuesday and Thursday mornings, our system allows you to block off that time when scheduling your classes so that your classes do not interfere with your work schedule. Likewise, you can visually indicate periods of time that you really want to take classes during, as well as times when you do not want to take classes, but you will if necessary. This is simply a visual tool in order to conceptualize free and unavailable blocks of time you have during the week.

    The “Add block” button functions so that you can choose to add a block of time or a class. When you add a block of time, you can indicate your availability during that time and color code it accordingly. When you add a class, that class will be added to the schedule during its meeting times. You are able to sift through different saved classes, as our system links up with the course browser, and add them to specific schedules. Those schedules can be saved in a repository of saved schedules.

  4. Tasks. Define 3 tasks that a user can perform using your prototype. One of these should be your most risky task, the one that is the most central to your system. Explain any information a user would need in order to accomplish this task using your prototype.

    1. Please switch schedules from “Spring Schedule” to “Backup Schedule”, and then add a time block.

    2. Please make a new schedule and name it “Backup 2”.

    3. Please take CS 204 off of your Spring Schedule.

  5. Wrap-up. Ask the user closing questions about their general satisfaction with your system and any further comments.

    "How satisfied would you say you are with the functionality of our system keeping in mind our goal of making Course Registration easier for those with time-based preferences? Keeping in mind that this prototype isn’t completely functional back-end wise."

    1. View usability test transcripts:

General Usability Testing Summary Analysis

We conducted three different user interviews using our 1.0 prototype. All three users gave overall good feedback and found that our prototype was successful in conveying its intended goal. Users feedback comments discussed similar frustrations regarding certain interactive elements (that were not fully functional at the time of testing) and will be reflected in the recommendations portion of this report.

The most common frustrations included “does wish that there was more control over time blocking, wishes you could put the same block on multiple days (like Mon/Thurs, Tues, Fri), and also wishes the time blocks could stay static as you switch schedules” and “the thing that was the most frustrating was that I could not figure out how to properly add a time block”. One observation that will be reflected in our 2.0 prototype is the naming of labels when creating a new schedule, as one user tester had difficulty in creating a new schedule due to the unclear button labeling. The user “took quite a long time and one wrong click to find connect that the button for this task would be ‘save schedule,’ was looking for ‘new schedule.’.....feels that the ‘save schedule’ should be renamed ‘new schedule’.” We also had comments on the toggle button, “hopes that the inverted buttons tabs (for classes) are fixed as the computer feedback isn’t as clear as it could be,'' which, while the button was dynamic and responsive as it did take a way the respective class, the color of the toggle button was inverted in the parameter of the button due to coding difficulties, not properly giving the feedback we do need for this aspect of the interface.

Aesthetically, the interface succeeded in the #8 Nielsen Heuristic Evaluation category of Aesthetic and Minimalist Design, as the layout, color scheme, and amount of whitespace of the interface was not a problem for the users we tested our 1.0 prototype on.

Individual Summary of usability Interviews

Test 1 Summary
  • Add a function that allows you to repeat a time block on certain days of the week for a certain period of time. For example, if I had to work every Monday from 8:00-9:00 for the month of December, this function would allow me to add just one repeating block rather than reprogramming it.

  • Fix the add block function so that it actually goes in at the programmed time.

Test 2 Summary
  • More control over time blocking

  • Fix toggle button to in order to give more clearer user feedback

  • Learned from usability testing: ideas in prototype are being successfully communicated even though not all aspects of the prototype are completely functional

  • Color choice and whitespace scheme are successful in keeping the interface less confusing, and easy to navigate during a stressful process

Test 3 summary
  • User had difficulty creating a new schedule: Took quite a long time and one wrong click to find connect that the button for this task would be ‘save schedule,’ was looking for ‘new schedule.’.....feels that the “save schedule” should be renamed “new schedule.”

Our recommendations to be reflected in prototype 2.0

  1. Renaming “Save Schedule” to “Save New Schedule.”

  2. Users can now add a time block that corresponds to the actual input they give the pop-up form. However, the schedule only updates after resizing the browser, which was something we weren’t able to fix in this prototype implementation. There are also restrictions, such as needing to type in the day fully spelled out (ie. “Monday”), and the time has to be inputted “military style” to be processed correctly (ie. 1:30pm = 13:30). This is something that would be streamlined in a future prototype, or perhaps fixed through creating a dropdown menu with pre-populated times. I attempted to add tooltips to the modal input boxes to inform users of how to input the days/times but was unable to accomplish this.

  3. The toggle switches now work to give proper feedback when toggling on and off classes on the schedule.

  4. Added a “registration” button to mimic registering for the saved schedule on view but has no functionality currently.

  5. To note: Being able to choose classes from the course browser and adding them to the saved schedule seems to be outside of the scope of our timeline because it would require a web scraper to read in all classes and their times in order to populate them on the scheduler. For this project, we are just prototyping the process and look and feel of this new course scheduler, so being able to search for classes isn’t necessary to be reflected in our second prototype.

Our prototype 2.0 takes into account the needs of our target users, students who work, but more broadly addresses the concerns of all students, by giving students a more visual platform to schedule and register for courses, linking the course browser from which to add classes, updating life which classes are full, as well as adding functionality to schedule around pre-determined time-blocks for an optimal schedule. Our team created a prototype that is visually appealing, adheres to Wellesley College's visual identity guidelines, and is intuitive to use, so come registration, a student simply has to create a schedule and click the "register" button, avoiding the confusing and user-taxing steps of the former registration system. A very similar system has now been implemented for Wellesley's new registration system, and this project was reviewed by the registration system revision committee to incorporate the needs and research of students.

Link to Prototype 2.0