How might we help UBC students make better decisions on which electives to take?
Timeline: Oct 2017-Apr 2018
Platform: Android
My Role: Design Lead
Tools: Adobe XD, Illustrator
Recourse is an Android mobile application that helps UBC students to make a more informed choice for elective courses. Users can post comments, insights and advice for other students. The app was created to curate the overwhelming amount of courses available.
This was a project created within UBC Launch Pad, a student-run software engineering club. 
Existing Solution
The current way to find your perfect elective has many pain points. When you hear about a good course via word of mouth, its hard to remember the course code, and the integrity of the recommendation is questionable. When searching for courses on your own, UBC shows all courses in an extensive list that becomes overwhelming to browse, putting the user in a state of analysis paralysis. In addition, the system shows you whether you have scheduling conflicts or whether the course is open only after clicking into it.
Our Solution
While RateMyProf also has a review system, Recourse provides curated courses for each individual user. Curation is based off of whether they have friends in the course, the content of previous courses they've taken, and tags they often use. By replacing the existing approach of asking your friends one-on-one via word of mouth, the user is now able to access their entire network.
Design Constraints
As our app is unaffiliated with UBC, we could not implement sign in with CWL (Campus Wide Login) to automatically load in student data. Without CWL, one cannot register in a course on the app. This meant that Recourse would have to work alongside the existing website. As our team was designated as an Android team, we embraced a "mobile first" ideology. 
Choosing electives is hard. There are many factors to consider that affect a student's ability to take the course as well as their motivation to attend class. How do students make their decisions? I asked them to list their top considerations, then organized them into two sections:
These considerations informed the information hierarchy for each course card. After exploring a variety of options, I settled on a layout that reflected these insights.
Multiple Card System
How can decision making be translated into visual design? Keeping Hick's Law in mind, I opted for the multi-card approach because of Recourse's emphasis on curation. Less options can be shown because the courses that appear are the courses the user wants to see. Multi-card systems emphasize browsing over searching, which corresponds to the target user's behaviour.
New users are required to connect to Facebook and upload their schedule before seeing course suggestions. This allows them to reap one of the largest benefits from the app - the ability to see what courses their friends are taking. By avoiding course conflicts, a common pain point is averted.
Rating Courses
The main parameters for each course are easiness and quality of content, which follow the hierarchy of bonuses that users want in a course. By showing each question one at a time, cognitive load is reduced.
Visual Design
I aimed to communicate dynamism in my design elements to convey the push Recourse was making towards better education, as well as a redirection and rethinking of how course scheduling works. As course scheduling isn't the most exciting activity, life was added into the app through arrows, gradients, vibrant colours, and energetic animations.
However, upon first hearing our app name, some participants believed it involved redoing or retaking a course. As I have never failed or retaken a course, I had not thought of this possible connotation.
If I had more time with this project, I'd like it to be an all-encompassing solution. This would involve integrating a course scheduler to show different variations of what the student's schedule could look like, as well as a notification system for when spots open in courses.
Working in a software development club, there was a large emphasis on immediately starting development. To advocate for the best implementation for the user, I learned to communicate the importance and reasoning behind my design decisions even if they extended the development process.
Back to Top