Pool — a UX case study

Reimagining university ride-sharing.

Background

Ridesharing has become a popular way to save money and be more eco-friendly. The UCD Rideshare FB group is the most common carpooling platform at UCD, with 31.9k members. However,

Students struggle with navigating through disorganized feeds and finding the right rides.

Over the span of six weeks, our team followed the human-centered design process, from conducting research to creating a high-fidelity prototype. We designed a new application for students that would simplify the process of and highlight important aspects of using university ridesharing.

Awarded: Best Prototype

Meet the team

Problem Statement

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.”

User Research

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).”

We chose to collect survey responses to gather a broader understanding of our users and a wider range of data, as well as conduct user interviews to gather more specific and qualitative insights. We were able to collect 79 survey responses and perform 5 user interviews. Our target demographic consisted of past and present college students from the ages of 18 to 28 who were familiar with university ride-share platforms. From the survey data gathered, we found that almost 60% of university ride-share users use the platform once every few months and that 80% of users listed cost as an important factor when choosing to ride share. Meanwhile, of the people we surveyed, over 50% did not use university ride-share platforms, and 30% of those students listed that it was because of a lack of advertising and awareness. The survey data and interview responses we gathered on the Facebook UCD Ride Share group and other ride share options also informed us that:

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 confusing.
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.

Ideation

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.

Mid-fi Prototyping

Our team started with a list of “How might we?” questions and then 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.

Usability Testing

We first 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.

High-fi Prototyping

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 plainer color palette with an accent color to emphasize important callouts.

Final Solution

From left to right: University Onboarding, Setting Preferences, Selecting a Ride

University Onboarding

Emphasizes the sense of trust built around university ridesharing by using university authentication at sign-up to ensure the app is being used by students.

Setting Preferences

Users can set their preferences to ease the process of searching for rides. For example, they can set pricing, view popular ride times, etc.

Selecting a Ride

Based on the users’ selected preferences, best-match rides are shown with relevant information. Users also have the option to save rides for later so they don’t have to worry about going back to search for them. Requested & Saved Rides will appear on the Dashboard so students can easily locate all this information in one place.

From left to right: Profile & Reviews, Confirmation & Payment, Ride Communication

Profile & Reviews

Users can set up a bio and have the option to link social media to make themselves seem more personable. Users can also view and write driver/rider reviews through each others’ profiles to gain a better sense of trust. From the profile, students can also view information about their past rides.

Confirmation & Payment

After joining a ride, the ride information will appear on the dashboard for easy viewing. To reduce the annoyance of constant back-and-forth communication between riders and drivers about ride details and cases when passengers can no longer make it to rides, we implemented a system where users would be prompted to confirm their ride by making their payment a day before the ride takes place. Keeping the payment within the app provides a more convenient paying experience, and creates a sense of security because the money will not be transferred until the ride is taken.

Ride Communication

Users can message the group of members of their current ride or message individual drivers and riders. Options to delete and archive old chats help the user organize their chats to keep this page from getting too overwhelming and cluttered with old, irrelevant messages.

Reflection

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

1. Design the driver perspective.
2. Explore what the app might look like during a ride.
3. Incorporating price adjustments and extra fees for special pick-ups/drop-offs.