Providing a ride-sharing experience at your fingertips

Problem

The company wanted to further expand its reach but realized that most of the clients were looking for a mobile app for ease of accessibility. They had a low-fidelity prototype that they wanted us to work off of.

Audience: The company already had 30+ prestigious paying clients who gave them about 500,000 users, a majority of which comprise of corporate companies. 

Need: Enhance the user experience by designing a mobile app to increase the user retention rate and improve the data collection process.

Opportunity: Create a compelling experience for potential customers who had not interacted with the previous platform at all. 

Validating the Problem

Each team member was working over the summer and this helped us get an understanding behind the thought process of interns/newly hired employees and the issues they face in their commute to work. One of our own team members had this situation and this helped us gain invaluable insight into the problem. Instead of creating personas for our users, we decided to take a different approach. We created a common story for a general use case of the application.

story

Our Strategy 

We were working on a strict timeline in an agile environment under which the solutions were to evolve through a collaborative effort of cross-functional teams. Adaptive planning and early delivery were imperative to ensure continuous improvement and evolutionary development. Our strategy looked something like this -

Our Strategy 

We were working on a strict timeline in an agile environment under which the solutions were to evolve through a collaborative effort of cross-functional teams. Adaptive planning and early delivery were imperative to ensure continuous improvement and evolutionary development. Our strategy looked something like this -

Our Strategy 

We were working on a strict timeline in an agile environment under which the solutions were to evolve through a collaborative effort of cross-functional teams. Adaptive planning and early delivery were imperative to ensure continuous improvement and evolutionary development. Our strategy looked something like this -

Our Strategy 

We were working on a strict timeline in an agile environment under which the solutions were to evolve through a collaborative effort of cross-functional teams. Adaptive planning and early delivery were imperative to ensure continuous improvement and evolutionary development. Our strategy looked something like this -

Our Strategy 

We were working on a strict timeline in an agile environment under which the solutions were to evolve through a collaborative effort of cross-functional teams. Adaptive planning and early delivery were imperative to ensure continuous improvement and evolutionary development. Our strategy looked something like this -

cpworld_strategy

Evaluating existing Website

The very first step was to get familiarized with the existing website and recognize the issues. We thought it best to test the app on mobile realizing it could give us a clear picture of the users' thought process, their interactions, expectations, and pain points.

old_website

Some of the comments that the users made during this process helped us recognize the notable issues that existed with the interface.

user_feedback

From this initial testing, we discovered there were several issues, big and small, that needed to be addressed. We did not want to get distracted from the final goal by going into multiple design directions, and so we decided to organize all these issues based on their severity levels. 

severity_rating

Mobile-App Redesign

The research findings along with the client requirements eventually helped us narrow down our goals. Due to the time constraint, we determined that it is imperative that the visual aspect of our design is informed by our holistic strategy first, and amplified by their aesthetic integrity second. We decided to focus more on the layout structure and placement rather than high-fidelity visual design, and honor the CarpoolWorld branding.

goals

Ease and Shorten Onboarding 

Onboarding is one of the most critical phases of an app user’s journey. Your initial interactions could be awkward and confusing or there could be an instant connection. In both of these settings, first impressions are everything! General research suggests that on average, 71% of all app users churn within 90 days. Onboarding helps clearly communicate “what benefit the app provides to users”. It gives them a heads up on what to expect and what it helps them accomplish.

onboarding_stats

The onboarding flow in the existing application asked users to fill out a lot of information before even showing them what the end goal is.

onboarding_flow

We decided to come up with a short, clear onboarding process that would enhance user interaction by reducing the cognitive load. We decided that informing the users exactly how many questions they’d have to answer upfront, in order to land on the matches page(a home page of sorts with all the listings of potential carpooling matches), would give them the motivation to complete the onboarding flow.

We decided to come up with a short, clear onboarding process that would enhance user interaction by reducing the cognitive load. We decided that informing the users exactly how many questions they’d have to answer upfront, in order to land on the matches page(a home page of sorts with all the listings of potential carpooling matches), would give them the motivation to complete the onboarding flow.

We decided to come up with a short, clear onboarding process that would enhance user interaction by reducing the cognitive load. We decided that informing the users exactly how many questions they’d have to answer upfront, in order to land on the matches page(a home page of sorts with all the listings of potential carpooling matches), would give them the motivation to complete the onboarding flow.

We decided to come up with a short, clear onboarding process that would enhance user interaction by reducing the cognitive load. We decided that informing the users exactly how many questions they’d have to answer upfront, in order to land on the matches page(a home page of sorts with all the listings of potential carpooling matches), would give them the motivation to complete the onboarding flow.

proposed_designs
skip

You cannot really predict the state of mind of every single test user. Keeping this in mind, we decided to have the ’SKIP’ option on the first page, to ensure that users who did not want to go through the onboarding could land directly on the matches page to see what options they have. Again, the app cannot give match suggestions specific to the users without actually getting the basic information from the users. This could also be accomplished by navigating the users from the matches page back to the profile page to fill in their information. We accomplished this by providing a small notifications icon at the top right corner of the page.

You cannot really predict the state of mind of every single test user. Keeping this in mind, we decided to have the ’SKIP’ option on the first page, to ensure that users who did not want to go through the onboarding could land directly on the matches page to see what options they have. Again, the app cannot give match suggestions specific to the users without actually getting the basic information from the users. This could also be accomplished by navigating the users from the matches page back to the profile page to fill in their information. We accomplished this by providing a small notifications icon at the top right corner of the page.

You cannot really predict the state of mind of every single test user. Keeping this in mind, we decided to have the ’SKIP’ option on the first page, to ensure that users who did not want to go through the onboarding could land directly on the matches page to see what options they have. Again, the app cannot give match suggestions specific to the users without actually getting the basic information from the users. This could also be accomplished by navigating the users from the matches page back to the profile page to fill in their information. We accomplished this by providing a small notifications icon at the top right corner of the page.

You cannot really predict the state of mind of every single test user. Keeping this in mind, we decided to have the ’SKIP’ option on the first page, to ensure that users who did not want to go through the onboarding could land directly on the matches page to see what options they have. Again, the app cannot give match suggestions specific to the users without actually getting the basic information from the users. This could also be accomplished by navigating the users from the matches page back to the profile page to fill in their information. We accomplished this by providing a small notifications icon at the top right corner of the page.

Improving Data Collection and User Retention

The existing website follows the process of explicit data collection, asking way too much information earlier, in order to obtain intentional data at face value. 

Improving Data Collection and User Retention

The existing website follows the process of explicit data collection, asking way too much information earlier, in order to obtain intentional data at face value. 

data_before

All this data required by the commuting habits survey can be taken in the background instead of asking those questions. This can be achieved using Google Maps API, which gives approximate distance and time based on location information.

All this data required by the commuting habits survey can be taken in the background instead of asking those questions. This can be achieved using Google Maps API, which gives approximate distance and time based on location information.

All this data required by the commuting habits survey can be taken in the background instead of asking those questions. This can be achieved using Google Maps API, which gives approximate distance and time based on location information.

All this data required by the commuting habits survey can be taken in the background instead of asking those questions. This can be achieved using Google Maps API, which gives approximate distance and time based on location information.

google_maps_api

Proposed New Features

As effective as Google API was, it could not collect all the information. We had a few recommendations on how to collect the remaining data.

1. SplitCost is a provision track carpooling expenses for trips and fuel. The feature addresses both the goals. The feature addresses both goals -

  • Retention rate - SplitCost gives a reason for people to keep coming back to the app.
  • Data collection - Users would voluntarily enter trip expenses (data) because the app, through SplitCost, is helping them manage their carpool costs.

We did a quick design mockup of the SplitCost feature.

splitcost_feature

"What if a user has a car, but does not want to drive every single day? What if you are a part of a big carpool group where everyone takes turns to drive?"

2. Take Turns solves this problem by enabling the users to put the requirements for their specific carpool group on the app. This would ensure that the app keeps track of the group’s schedule and the person responsible for driving gets a notification from the app itself. The Take Turns feature would encourage users to key in their information and thus promote the process of background information collection for the application

Gradual Data Collection

In addition to the auxiliary features we introduced, we also devised a solution for gradual data collection. This method would give the users enough time to familiarize themselves with the app and be satisfied with its service. Once the user needs have been fulfilled, the data collection process can be introduced gradually.

Final User Testing

With the new features designed, we created a prototype to test it at our respective workplaces.

Final User Testing

With the new features designed, we created a prototype to test it at our respective workplaces.

Final User Testing

With the new features designed, we created a prototype to test it at our respective workplaces.

Final User Testing

With the new features designed, we created a prototype to test it at our respective workplaces.

1

Our end users included friends and acquaintances who did not own a car and needed to travel to work everyday

Our end users included friends and acquaintances who did not own a car and needed to travel to work everyday

Our end users included friends and acquaintances who did not own a car and needed to travel to work everyday

Our end users included friends and acquaintances who did not own a car and needed to travel to work everyday

Our end users included friends and acquaintances who did not own a car and needed to travel to work everyday

2

👩‍💻

©️ Malvi Shah 2021