We conducted a few interviews with CULift users- ranging from a temporary time patient to users with permanent disabilities. We primarily focused on student riders themselves as opposed to faculty or staff members.From these interviews, we wanted to better understand how these users felt as they used CULift service to allow us to specifically target these pain points.
To get to know the student rider's experience, I conducted a few in-person interviews and also sent out a survey with the same questions. Research questions provided a framework for our online research, survey, and interviews. We asked interview participants questions such as:
In total, we interviewed 6 students who are using CULift or have experience using it for at least one semester.
We used an affinity diagram to identify the general scope of the project and decide which design direction we should be heading. This exercise, based on user interviews, proved to be very helpful in setting up the foundation for the rest of the design process.
As a reference point and to study how users move around the campus, I looked into two platforms- Uber and Lyft. Competitors are targeting the general public, excluding those with wheelchairs or physical disabilities. I learned how crucial accessibility support and live update of information is and should be a part of our solution to be competitive.
What is a student rider's journey with CULift?
I synthesized my qualitative data and findings into actionable insights through journey mapping.
When users encounter difficulties, what matters most is that the they feel their voice is heard.
User's action should be reinforced by thoughtful interactions and feedback so users can make decisions quickly and easily.
Ensure users the drivers will arrive on time and take them to their destinations on time. Communication should be available whenever necessary.
To better understand how we should design the core user experience, we first built a user flow. This helped us focus more on the overall experience and user needs and less so on the details that we can solidify later on. It also allowed us to communicate the entry and exit points more clearly with engineers
The designers and I took out our sketchbooks and drew out various ways for the home screen. We compiled and compared blueprints to figure out which data formats fit best and which elements were necessary for the MVP.
I tried variations of the home page, as seen above, to explore as many possibilities in this phase before narrowing down. I experimented mostly with how to group the functionalities of the app in a way that would provide helpful information to users.
In terms of constructing the home screen for students, I could think of either designing it in a vertical scroll or combination of a vertical and horizontal scroll. Both options had their own merits and downside. So I decided to run a quick A/B Testing on the home screen to see which option users will found useful.
Option A - A combination of horizontal and vertical scroll freed up more screen real estate, allowing users to see more components in one glance. Also, Option B made users scroll more than necessary, getting in the goal of providing ease of use.
Design C- We were concerned about the reachability with the button being in an unreachable zone or too small for errors,We considered Design C. We pursued this option since [Request Ride] feature should be easily accessible by users. The bottom-centered button would allow for easier and more efficient navigation by an easy Fitt’s law calculation and looking at the reachability map for iPhone.
After deciding and pinning down functionality, I did my final paper wireframes before digital low fidelity designs.
Option E- The mini-map of the user's ride did not provide helpful information to users as many were already aware of the campus' map. This option, which took into account text overflow, gave users essential information in a salient manner while freeing up more space in the home screen. Option E also communicated status update of current ride most effectively to users.
Option C- Following the design of current ride cards, we decided to pursue an option that did not have a map, for maps did not provide much valueto users. C arranged information in the hierarchy that was most useful to users and was more suitable for horizontal scroll.
Option B- During the initial testing phase, we discovered that initial design (option A) was making users prone to errors. When they wanted to request a new ride, they sometimes ended up pressing a Past rides card. In order to alleviate users' anxiety, we pursued option B which prevented users from errors with its background.
Option A- We initially considered adding live tracking of current ride, but decided against it because of technical feasibility and it would not prove to be useful for riders. CULift only allows rides to, from, and between campus buildings, so most of the trip takes less than 15 minutes and riders know the route well. Instead, we pursued an option where information regarding the ride, such as pickup location, drop-off location, and repeatedness is clearly indicated. We also decided to replace the driver's number with call button because drivers expressed that they do not want their personal information shown to the riders.
Option B- We decided to pursue Option B for request rides flow because it separated the process most clearly to users. The main part (location, time, and review) and subparts (pickup location, etc.) were also distinguished clearly and communicated each step better than other options.
We have the large responsibility of making our designs accessible as we move to high-fidelity. With around 4.5% of the world color-blind and around 17% of the world having other visual impairments, color contrast and accessible visual interfaces are essential, especially on college campuses. This issue mattered more for this project as Carriage aimed to provide disability support. All colors used in the high-fidelity app design were AA~AAA contrast rating for the size of the text.
This project was different from the ones I tackled before because accessibility mattered more than anything else. I learned to value the trade-off between following traditional designs and pursuing unique designs to answer users' needs. Following common designs would make the development phase much easier but, in the end, users matter more.
We will be expanding to include the dispatcher website into the project as well. I’m excited to work harder with the team to solve accessibility problems on Cornell campus and I look forward to the progress to come.