POOL
Reimagining university ridesharing.
Carpooling through rideshare platforms is becoming a popular way to save money as well as leave a positive impact on the environment. With so many users, students struggle with navigating through disorganized feeds and finding the right rides. The UC Davis Rideshare Group on Facebook is thriving with 31.9k members and is flooded with posts from college students searching for rides to neighboring cities.
The project was prompted by Design Interactive, an on-campus UX organization that hosts a 6-week cohort sprint every Fall and Spring. My team was tasked with designing an app that aids all of the pain points university students have when using the "UC Davis Rideshare" Facebook group. We followed a human-centered design process, working through iteration after iteration of app structure and visuals. At the end of our sprint, we were given the opportunity to present our final prototype to guest judges who are UX Designers at Netflix, Microsoft, and Nvidia.
Communication between riders and drivers is difficult and frustrating, especially due to having to switch between multiple apps to keep track of messages and/or payments. Searching for riders/drivers that match one’s preferences is time-consuming and confusion. After doing more research, we formed a more detailed problem statement.
Current university rideshare platforms are confusing to navigate, feel untrustworthy, and lack room for personalization.
To get started, we conducted literature reviews to find out more about our topic as well as other existing ride-share platforms. We then created a research goal to help us maintain a focus when generating research questions to ask users.
We want to learn more about the experience that drivers and riders go through when using existing ride share platforms (UCD Ride Share group).
From the survey data gathered, we found that:
• 60% of university ride-share users use the platform once every few months
• 80% of users listed cost as an important factor when choosing to ride share.
Meanwhile, of the people we interviewed:
• Over 50% did not use university ride-share platforms
• 30% of those students listed that it was because of a lack of advertising and awareness.
1. Communication between riders and drivers is difficult and frustrating, especially due to having to switch between multiple apps to keep track of messages and/or payments.
2. Searching for riders/drivers that match one’s preferences is time-consuming and confusion.
3. The establishment of trust between riders and drivers gives students a sense of safety, which is also why current users gravitated toward university rideshare platforms.
The bolded keywords represent common themes that our participants expressed value in.
Using these main takeaways, we were able to start affinity mapping and forming HMW questions to guide our solutions and sketches in the next phase.
1. How might we streamline communication between drivers and riders about ride details?
2. How might we create an intuitive way to filter for driver/rider preferences?
3. How might we allow for flexible prices for riders/wages for riders?
4. How might we establish a sense of trust when matching riders to drivers (or vice versa)?
We individually sketched design solutions to each of our “How Might We” statements, which focused on features that established a sense of trust, transparent communication between drivers and riders, and a filtering mechanism.
After discussing our sketches, we collectively decided on the following features, which aligned with our research and “How Might We” statements.
1. Users log in by choosing their university and then signing in with their student ID to ensure that only current students are using the platform.
2. On users’ profiles, they can link their social media and add interests to personalize and allow others to see mutual connections
3. Riders find a ride by first filtering their preferences, and choosing from relevant driver options. Filters include pick up & drop off location, date, time, and price.
4. After picking a driver, riders send a request to join the car. Once they have been accepted into a car, the user is automatically added to a group on the chat page with the other riders and the driver. If the user wanted to individually message someone, they would click on their profile and send a private message from there.
5. On the Dashboard, users can find their pending requests, current rides, and past rides all in one place. There will also be a section for announcements, where users will be reminded about payments, chat messages, etc. They can also see and scroll through the explore page.
6. If riders can not find a ride after filtering and looking through driver options, they can post with a description of what they are looking for, and this post will be listed on the explore page. The explore page can be sorted to show only riders or drivers’ posts.
7. Users can heart drivers and riders they enjoyed interacting with. After a ride is complete, users can also leave a review.
Once we started mi-fi prototyping, we noticed some organizational challenges with coordinating the driver and rider flow, so we decided to primarily focus on the rider-flow. We also had a hard time implementing the hearting feature, since it’s purpose overlapped heavily with the reviews.
We individually sketched out our ideas for solutions to the common pain points that we collected from our research. We met to share our low-fidelity sketches and then each marked the different features we liked from the different sketches. Then, we created a site map to go through the various user processes within the app.
We had our users disclose how often they use rideshare and their goals for using rideshare. Then, we gave them their first task which was to find a driver to book a ride with. In the case that they wanted to save a ride for later, we asked them how they would go about that. We also asked them how to go about finding pending requests, how to confirm requests and pay for requests. Moreover, we prompted users to message their drivers individually and message a group chat with the other riders. We also had them view driver reviews, your personal profile, ride history, and settings to switch from the rider to driver.
As we moved into developing our high-fidelity prototypes, we decided to reorganize the rider and driver flows, nesting the settings to switch between the two in the profiles/settings page, to minimize confusion we found during user testing. Other changes we implemented were reorganizing information on the ride cards, as well as including an archive feature to minimize the chat page.
Our team also created a design system to ensure consistency between our frames. We opted to use a simple, easy-to-read font, and chose a muted color palette with an accent color to emphasize important callouts.
Research Insights 1:
➡️ Students feel safe using the UCD shuttle because it is run by the school and has credibility
➡️ Safety was the most important aspect for 2/3 of the Facebook Rideshare users
Solution 1:
University Onboarding
Emphasizes the sense of trust built around university ride sharing by using college-specific authentication at sign-up. This ensures that the app is being used by students only.
Research Insights 2:
➡️ There's too much scrolling through posts about ride offers and people searching for rides
➡️ The hashtag feature on UCD Facebook group is helpful for filtering out certain riders and drivers
Solution 2:
Filter for Ride Preferences
Having a filter can ease the process of searching for rides instead of endlessly scrolling through irrelevant posts on the FB group feed.
Research Insights 3:
➡️ It can get hard to keep track of the people you have already messaged
➡️ Sometimes drivers don't post updates when spots are taken for their trip
Solution 3:
Requesting and Saving Rides
Keep track of which rides you've requested in your Dashboard. Save rides for later in case your request is not accepted.
Research Insights 4:
➡️ Inconvenient to switch between Facebook and Messenger to communicate with other students
➡️ Communication with drivers and other riders can be difficult
Solution 4:
In-app messaging
Make group communication easier to discuss ride plans and get to know the students you're carpooling with.
Research Insights 5:
➡️ Constant back-and-forth between riders and drivers about ride details
➡️ Cases where passengers can no longer make it to rides
Solution 5:
Confirmation and Payment
Keeping payment within the app provides a more convenient experience, and creates a sense of security because the money will not be transferred until the ride is taken.
Research Insights 6:
➡️ It's convenient that students in the facebook group can see the public profile of other students and get a sense of what they’re like
➡️ It's better to ride with drivers who share mutual friends
Solution 6:
User Profile & Public Reviews
Students can set up a bio and have the option to link to social media. Users can also write driver/rider reviews on each others’ profiles so other students can view information about their past rides.
Takeaways
We learned that the product design process is non-linear, and that research and usability testing are crucial to incorporating new features. We discovered that less is more when turning essential elements into something easily accessible.
Next Steps
In the future, we hope to design the driver perspective, explore what the app might look like during a ride, and incorporate price adjustments and extra fees for special pick-ups/drop-offs.
