Wellesley Course Browser Redesign
New and improved course browser for Wellesley College Students.
Created as part of an informal designathon among Wellesley students over winter break.
Role
Designer, Researcher
Timeline
Jan 2021 (2 weeks)
Collaborators
Zoe Allen, Julie Lely, Yuji Chan, Adhel Geng
Check out our live site here!
​
Goal
My partner Julie and I focused on the distribution requirements section of this design. We wanted to design a feature that allows Wellesley students to keep track of which distribution requirements they have and have not completed.
Research
The Issue
All students at Wellesley College must take a certain number of classes in various disciplines (natural sciences, foreign language, etc.) in order to graduate. Currently, Wellesley does not house all information regarding students' distribution requirements in one online space. Furthermore, Wellesley does not provide any method of keeping track of students' completed and remaining distribution requirements. This is a source of stress, confusion, and inconvenience for Wellesley students.​
We spoke with several of our Wellesley peers to understand their grievances better, and developed a user persona.
The Current Process for Tracking Graduation Requirements
​​​1) Consult the Wellesley College website for information about graduation requirements.
.png)
3) Count up completed requirements and determine how many remain.*
.png)
2) Open the Wellesley course catalog and check all previously taken classes to see the requirements they fulfilled.
.png)
4) Access the Wellesley Course Browser and search for classes that satisfy the remaining requirements.**
.png)
*There is no standardized way for students to count their completed requirements. This seems to be the primary frustration. Some use a spreadsheet, some use pen and paper, etc. Pictured under step 3 is the document I created to track my own requirements.
​
**The current Wellesley Course Browser has a function that allows students to filter classes by certain distribution requirements, but it tends to be quite glitchy. Therefore, most students told us that they do not find this feature useful.
​
How Can We Solve These Issues?
After speaking with our users, we narrowed down two primary problems:
Pain Points
There is no standardized way for users to keep track of what requirements they have and have not fulfilled.
Solutions
Implement a function that automatically identifies the user's outstanding requirements and displays it clearly.
Users must access several different websites and documents to complete all steps of the requirement-tracking process.
Streamline process and reduce bouce rate by consolidating all steps into one website.
Design & Iteration
Reducing Bounce Rate
In order to increase user convenience and reduce bounce rate, we sketched out a wireframe design a of distribution requirements page residing on the same website as the course browser. Users can easily switch between the two.
​
On the right, users can type in the names of courses they have completed. If the course fulfills a certain requirement, it will automatically appear under the corresponding distribution on the left. This creates a visually clear list of which requirements the user still needs to complete.
Presenting Key Information
Because it is critical to display which requirements they the user and has and has not not fulfilled, we created a few different prototypes and performed A/B/C tests to assess which approach worked best.
​
In the following designs, we experimented with a mixture of dropdown menus and auto-completed charts. In each design, the initial view shows whether an entire requirement has been fulfilled, while expanding the content reveals any courses that have counted towards that requirement.
​
Behind the scenes, we also used Firebase to code a database of all courses offered at Wellesley and their corresponding distribution requirements.
Design A
Each distribution requirement has its own collapsible row.
Design B
Each distribution requirement has its own collapsible chart.
Design C
Some distribution requirements have their collapsible own chart, while others have their own collapsible row.
The majority of our test users preferred Design B due to its visually simple and concise layout. We combined the collapsible charts for each distribution requirement with a "Quick Add" function (as seen in the wireframe above) to create the follow design:
Refining Our Key Interaction
While the primary function of this design is to show which requirements are and are not fulfilled, the majority of the user's action lies within the "Add Classes" feature. Once the user enters their past classes, the product essentially does the work for them. We went through a few iterations of this feature to find the most efficient approach.
Iteration #1
This design prompts users to enter their previous classes in two different sections: "Main Distribution" and "General Requirements." This is how graduation requirements are explained on the Wellesley College website.
However, user testing revealed that most students do not know the difference between these categories. Dividing the two only created confusion.
Furthermore, some students had taken classes that did not exist in the course database we coded (e.g. transferred credits from studying abroad), and therefore were not accepted in either the "Main distribution" or "General Requirements" sections.
This raised a question that we had not previously considered:
How do we handle requirements fulfilled via courses outside of Wellesley?
Iteration #2
To eliminate confusion over "Main Distribution" vs "General Requirements," we created one "Automated Add" button where users can enter any class they have taken at Wellesley.
We also wanted to address the issue of adding "atypical" classes. We created a "Manual Add" section where the user can add a course and select which requirement(s) it fulfilled, regardless of whether the class is in our course database.
This means that students will be able to see distribution requirements fulfilled via transfer credits from other institutions, or credits from Wellesley classes that no longer exist in the database.
User adds Foreign Language requirement via transfer credits from a different instituions.
Enhancing Discoverability
​A few test users had previously complained that the "Add Courses" section was not discoverable enough. We added tooltips to both the "Automated Add" and "Manual Add" sections to guide the user to add their classes correctly.
Accommodating Outliers: Foreign Language & Quantitative Overlay
A couple of users also pointed out that two requirements (Foreign Language and Quantitative Reasoning) can be fulfilled in multiple ways. For example, a student may have fulfilled their foreign language requirement with AP credits from high school, rather than through a class at Wellesley. These cases are a bit different from the ones we accommodate with the "Manual Add" function because they may not come from a "course" at all.
We designed a separate, brief survey feature to collect users' information regarding these "outlier" requirements, which will then automatically fill in those requirements accordingly. This survey appears when the user begins to enter their course history.
For the Foreign Language requirement, users can choose to enter a course for credit, or choose from 3 alternative methods.
For the Quantitative Reasoning and Multicultural requirements, which are fulfilled a bit differently from other requirements, users answer multiple choice questions to indicate whether they have satisfied all requirements.
Course History Group-Add
Lastly, we decided to design a way to add a large amount of past courses at once. For users who are further into their degrees and have many courses under their belts, adding every single class via the "Quick-Add" function could become tiresome.
The following Course History survey, which appears when the user uses the website for the first time, allows the user to enter a semester's worth of courses at once.
Enhancing Discoverability
As we approached the end of the designathon timeline, we performed one final round of testing to clean up any remaining issues. Positive feedback confirmed that we had met our MVP.​
Takeaways
The user is always right! As a Wellesley College student myself, I overestimated my expertise and, at times, assumed that my own experiences would be representative of most Wellesley students' experiences.
Performing several rounds of user testing with Wellesley students and seeing how their preferences differed from my own was an important reminder of the importance of truly listening to the users, being cognizant of my own biases, and keeping an open mind during testing.