Carriage Case Study
Carriage is a web and mobile platform designed to improve the user experience of scheduling, completing, and monitoring CULift rides for administrators, riders, and drivers. CULift is the shuttle service used by students with temporary and permanent mobility disabilities at Cornell.
Team
Cornell Design and Tech Initiative
Skills
Visual Design, Interaction Design
Tools
Figma
Timeline
March 2021 - May 2021
Problem
Administrators want to save time and experience less stress at work, but they can’t because they:
Waste time scheduling every recurring ride
Can’t schedule rides in advance
Adding Repeating Rides
Solution
1. Custom repeating rides
Instead of taking time to schedule a recurring ride every time it occurs, administrators can save time and schedule it once.
2. Date Input
Before, administrators only had the option to schedule a ride the day of. A date input gives them the flexibility to schedule rides far in advance. This reduces their stress because they don’t need to schedule rides at the last minute.
Explorations
I explored different interactions for the user to take when customizing their repeating rides. On the other hand, option 2 has a dropdown that opens above the other fields.
Pros:
Avoids using a dropdown within a modal
No custom end date reduces clutter and might be unnecessary because most repeating rides stop at the end of the semester
Cons:
The user might think the expansion panel is hiding other fields, could be mistaken for a dropdown
Pros:
Includes end date for recurring events that stop before the semester ends (e.g. clubs)
Requires no extra work for most users because, by default, repeating rides stop at the end of the semester
Cons:
Dropdown within modal looks cluttered
Final Prototype
This video shows a demonstration of the user scheduling a custom repeating ride.
Problem
Administrators need to quickly find individual students' profiles in order to more efficiently perform their core responsibilities and save time for other tasks.
Filtering Students by Status
These responsibilities are…
1. Monitoring and following up with students with repeat tardiness or no-shows
2. Deactivating and activating students as needed
3. Using student data as well as ride data to determine how well service is performing
4. Identifying students that need special accommodations
Original Design
Currently, the administrator wastes time scrolling through all active and inactive students to find the student they are looking for.
To solve this, the product managers on my team assigned me the task of designing a feature to filter students by active and inactive.
Option A: Checkbox
Pros:
Shows that seeing inactive students is low priority
Shows active students by default
Cons:
If active students fill page, user must scroll for inactive students at bottom
Option B: Tab Navigation
Pros:
Shows active students by default
Don’t have to worry about scrolling to see inactive students
Cons:
Implies that user often checks inactive students
Final solution: Checkbox with inactive students at top
Why:
No need to scroll to see inactive students
Checkbox shows this feature is low priority
Since users only want to activate a specific student, they don’t need to see active and inactive students at once
User can easily hide inactive students again after they are done activating a student