Go Buddy: Ride-Sharing App | UX Case study
A design assignment I did during my job hunting spree
Design assignments are the most common part of the recruitment process in the design industry and for me, the dreadful part of the process. I’ve never liked them. One of the reasons being that they sometimes ask you to invest more than 2 days and even after spending 2–3 days in it, you won’t get proper feedback from them. But as long as they are the norm for the recruitment process, we have to do it.
Here I have written about one of the case studies I did for one of the company. It took me 3 days to finish the assignment from research, ideation to documenting everything.
Problem Statement
Design an android app for car sharing which is powered by real-time data & availability. If a user (ride seeker) needs to get somewhere e.g. commuting to work, why not get a ride from someone who is traveling in the same direction, share costs, get a comfortable ride and be faster compared to buses or metro. On the other side — the app should enable the user (driver) to get co-riders who are traveling on a common route.
The app could work globally and provide the only locality based search results of ride seekers and drivers.
Analyzing the problem
The problem statement mentioned about 2 types of users for the car-sharing app-
- Ride seeker- One who wishes to get somewhere by a shared car.
- Driver- One who wishes to share his ride with co-riders.
The designed solution should serve both types of users.
Design Approach
I used the double diamond approach for the assignment. The double diamond approach starts with the exploratory research around the project, tries to gather as much as data possible with the use of a user research method (In our case, user interviews) to define the scope of the project. Once the scope is defined, multiple solutions are evaluated and tested against the user to arrive on the final solution.
Due to the shortage of time, I cannot test my designed solution.
User Persona
I started by defining two hypothetical users for the project and listed their different goals of the day. The designed app should serve both the goals of the two users- Rider and Driver.
Assumption
- It is assumed that a user can use the app as a driver and a ride seeker/rider both.
- The app will list nearby riders/drivers in the user’s area and he/she will choose a rider/driver on his own discretion which means journey time depends on the user’s choice of routes.
Research about similar companies
I started by taking notes about the different ride-sharing app in the market which people generally use like Ola Share and Uber Pool. I checked out their flow of booking a ride. I checked out the booking flow and also looked for important information required for booking a cab like prices and ETA.
In order to book a cab, User has to enter pickup and drop location. The nearby driver is assigned automatically by the app and the user has to wait till the driver arrives. He can also track the location of the cab.
User Interviews
The next task was to understand the user’s concerns and expectations for a ride-sharing service. For this, I designed a small questionnaire.
Questionnaire
The idea of the questionnaire is to keep it open-ended and try to gather as many details as possible around a ride-sharing service. The questionnaire is provided below:
1. What is your preferred mode of commute? (personal vehicle, private taxi, shared taxi, and public transport)2. What is your most preferred ride-sharing service and why?3. Can you describe your most recent shared taxi booking experience?4. What do you like most about shared taxi?5. What do you think should change about them?6. If given a service that allows you to share the car of the nearby drivers driving on your route and split the cost, Would you do that? Describe your answer.7. If given a service that allows you to share your car with nearby riders traveling on your same route and split the cost, Would you do that? Describe your answer.
Analysis
I took telephonic interviews with my 7 friends. Here’s what I got:
- I found out that most of the people prefer shared taxi over public transport like buses/metro because they are economical and readily available.
- Out of the available services, People trust Uber Pool because of its brand value and its clearer interface makes it super easy to book a ride.
- Each of the people I interviewed is critical about the driver and their safety. They want to completely trust drivers before they book their ride. Similarly, a driver wants to ensure who is riding with them.
- Some people raised concern that their routes get longer because of the intermediate drops. It would be better if drivers pick on the same route only or not very far from the route.
Problem Definition
After gathering all this information, I converted the problem statement into sets of “how might we” statements using “How might we” method.
- How might we enable the user to request a ride for a route?
- How might we enable the user to share his ride in his route?
- How might we generate trust about the driver/ride seeker?
- How might we ensure the user to reach his destination in minimum time?
Information Hierarchy
I created a simple flow for requesting and sharing the ride. The user starts with entering their destination and then the app asks to choose “Request a ride” or “Share a ride”. While requesting a ride, User can also select from other services like Ola and Uber (during user interviews, most of the users preferred ola/uber over any other service). Also, There might be the case when no go-buddy driver is unavailable.
Initial Sketches
Using the information hierarchy, I created wireframes on the paper. I tried to make them as detailed as possible to ensure that minimum changes needed to be done while I design mockups on Sketch.
Wireframes
Rider Flow
Apart from the natural flow of booking, I added a screen with driver reviews from past riders just before confirming the driver. This instills trust for the driver and the user can safely book him without any worry.
Driver Flow
Here I tried to compare different riders on the basis of extra travel time. The driver can check how their route and drop times will change with respect to the different riders and he can choose the rider which cost him minimum extra travel time.
High fidelity Mockups
I converted the wireframes into high fidelity mockups using Sketch.
Rider Flow
Driver Flow
Final Submission
I then created a quick prototype in Invision and started documenting my process in a medium draft. Then I submitted a private link for the draft as a submission. I prefer Medium for sharing my case studies because it gives a better UI to an article and also gives the ability to zoom in images by tapping.
The whole process took 3 days and I did receive a call for the next round of the interview.
Future scope of improvement
After submitting the design solution, I realized certain things that could be made better-
- Remove pickup and drop location input fields in driver/rider selection screen to provide more real estate to the map for showing the change in routes.
- Since driver selection is done on the basis of the reviews, how the app will promote new drivers to use the app?
- While driving, the driver will not have enough time to read full reviews of the riders or even check how the route is changing. So, He will select whatever rider will have the highest rating or by quickly scanning the route. So there’s a need to reduce this friction and make the rider selection easier.
- Provide a feature to the rider to tell about the maximum time they can tolerate while sharing the ride with other riders such that if the travel time increases by a certain number, It notifies the driver to stop taking more pickups and give priority booking to riders. Businesses can also earn money by charging users for availing such a feature.
