Carriage: Efficient Transit for Students with Disabilities
Product Designer | 16 Weeks
Overview
A product which works with Cornell’s CULift to provide transportation for students with disabilities by improving task flows for ride scheduling, dispatching, and monitoring.
Admin/Driver Cards
Standardizing cards for better visual understanding
The original admin/driver cards included their schedules which led to an uneven display of employees. This led to confusion as to why some cards were bigger than others. Users wondered if bigger cards meant the employee was more important than another who was displayed with a smaller card,
I wanted understand: How can I standardized admin and driver cards?
Original Employee Page
Original Employee Card
Iterations
In order to alleviate differently sized cards, I thought about different interactions which could be integrated.
A. Scroll
B. Hover
C. Drop down
D. Quick view
I decided that the inclusion of these interactive elements were not user-friendly as it forces too many actions within a small area. I then focused on including only the most important information necessary to be displayed on the card (name, role, and identifier code).
E. Role Tags
E. 1
E. 2
The final design (E.2) includes the role directly on the card rather than in the form of bubble tags with icons.
I ultimately chose this because:
In E.1, the floating label could potentially yield accessibility issues for screen readers
In E.2, the information is clustered together within the same area which aids in scanability
No Show Reporting
Error recovery for Carriage Drivers
Drivers must report students who do not show up for their rides, but sometimes this report can be incorrect. They could have mistakenly not seen the student or the student could have been in a slightly different place than the driver expected.
I wanted understand: If students are reported as a “no show” on accident, how can drivers fix this? In other words, I wanted to create an error recovery method for drivers.
Ride History
No Show Reporting
Iterations
I wanted to create a card which would mark within the history page that the rider was a “no show”. This would be the beginning of my task flow.
A. Dark tag
B. Dark banner
C. Light tag
D. Light Warning
I explored iterations through dark and light indicators. Designs A, B, and C resembled buttons and would mislead users by creating a false affordance in that they are interactive which led me to favor explorations C and D
Final Flow
The final design (D) is one which does not look interactive and does not overemphasize the information. Ultimately, I chose this design because…
The student is marked without the information tag overshadowing the rest of the card
It does not mislead the user by seeming interactive.
