15-minute reading: This article will introduce you step by step an iteration of a redesign.
"We Pair Together"
"We pair together" is a research-based UIUX design for Uber.
This project aims to solve a problem that will benefit UberPool users who want to pair with a person that they know.
We work in a team of three. Our design started with user research and is finalized by user testing.
Targeted User: Young people who use UberPool for joint activities
Problem statement: Passengers who use UberPool want to pair with the people they know for safety and money-saving.
Our approach: POOLFRIEND!
In our team of three, I was responsible for generating and finalizing the visual elements for PoolFriend. I am extremely strict from every pixel to the whole style. I revised the user interface for our design several times because designs will never be perfect.
Moreover, as a research-based project, I was the main contributor to design our survey and interview questions. I believe that if precisely designed, our team would have a more proficient point of view on our targeted users who has real needs to be met. What's more, the survey has narrowed down our targeted user to young students and employees. This helped, later on, allocate our user testing participants. By narrowing down the targeted user to a specific attribute and context, we had our design advanced after every round of user testing.
Finally, Poolfriend for Uber turned to be a precisely positioned and professionally polished project.
We collect data from 47 users who used Uber daily and find 6 participants who have specific stories to tell. We interviewed these 6 participants and came up with the core pain points and users' desires.
Specifically, we will be able to:
Understand contexts when users would use carpool option
Survey: The purpose of the survey was to collect large data set on opinions about the current ride-sharing experience. Surveys are helpful in helping us describe the characteristics of our targeted population.
Understand painpoints when group riders share a ride
Interview: We wanted to hear their stories about sharing rides, and to understand the inconvenience or concerns they have while using the “add stop” feature. We wish to use the interview findings to find patterns among participants and summarize them into pain points that we could take into consideration in the redesign.
Core pain points:
1 Users have no control of what people will they be paired with when taking an Uber pool
• Several female participants claimed that they would not take a shared ride at night.
• Most of the participants who do not like to use carpool function said that they don’t like to share a ride with strangers.
2 Users have no control of what time they will be picked up when using “add stop” function
• Time-convenience is extremely crucial for employed passengers
• Pick up time need to be punctual
Desire and wishes:
• Safety is the most important factor for ridesharing app
• Passengers want to make sure they are sharing ride with people they do know and meet quite often
2 Splitting fee
• Passengers want an easier way to split the money with their friends
• The riding fee has to be cheaper than independent rides
• UberPool user wants to know the planned route at the beginning of their ride
• Passengers who get on the car later need to know the exact route and arrival time
- How can we help Uber pool users save money and commute safely to work or group activities？
- Our approach: Pair them with people they know.
Based on our research, we found that young people are more likely to use the Uber pool (Because older people own cars! ). Thus, our personas focus on the 20-30 age group. These people are mostly students or recently graduated employees. These groups of users frequently involve in school activities, sports activities or social entertaining activities.
Another consideration is safety. This is why two of our personas are female since the female is considered a more vulnerable group during ridesharing.
We came up with a male college student, a female graduate student and a female employee for our persona. Their stories are based on some of our interviews and the pain points we gathered from research.
We found various existing transportation apps, including a direct competitor Lyft, and two indirect competitors Waze Carpool and Scoop, that offer similar solutions to our target users’ challenges. We analyzed each app’s strengths and weakness of our redesign.
After analyzing the unique qualities, as well as strengths and weaknesses of these three apps, we think extending the Uber pool option with users’ choice of who’s going with them will be the most effective solution to our target population. It allows users to take real-time carpool with people they know, and with certificated drivers in a broader region than where Waze and Scoop is available. Our extended Uber pool feature can ensure both user’s safety and cost-effectiveness.
Basing on the persona and referring to competitive audit, we create two distinct user experience flow of an extended function for Uber that will allow users to share a ride with the person they know.
1 Our first UX flow starts when the user opens Uber’s home page. Same as the existing user flow in Uber, users can first choose the destination and add a stop in between. Inspired by Waze Carpool we added an option to create a group for people who frequently wish to carpool together. When choosing to find a ride for the group, it will send a confirmation to all members in the group, who are allowed to edit their stops, and the trip begins after all members are ready. Our problem statement states that we want to help Uber users commute safely and efficiently with people going the same way, especially for our personas Helen and Sophia, the group function makes it safer and more affordable to share the ride with their teammates or co-workers.
2 our second UX flow also starts when users open Uber’s home page. The home page shows a map on the top half of the screen like the existing screen but has three tabs below to set the destination & pick up point, choose a car type, and option to add a rider. If the user chooses to add a rider from their contacts, Uber will send a notification to the new rider to confirm the trip. After confirmation from all riders, they can begin the trip. This flow is a better design for our persona Daniel who does not need the multi-rider regularly and frequently as Sophia and Helen do, so Danial can use the Add a rider tab to add a friend each time he needs to.
We then have two groups of UI sketch done, each corresponded to one flow. There are several screens that serve the same functionality in sketch 1 and 2. We tried to have different designs for these screens. Here is what we have generated:
Based on the UI sketch, we created paper prototypes for user testing, the first round.
1 Our first prototype corresponds to the first flow. We apply linear selection in this plan that enables users to enter information step by step. In most of the screens, we are keeping Uber’s current design. For example, the first two screens are almost the same as the welcome page and the page when the user selects the destination in Uber. The biggest change is that we assigned a name to the second stop, indicating that a new person may be picked up. After the user invites someone to the ride, the invited person will get a notification with the choice of join or decline. User 2 can then edit the pickup spot and start the ride when ready.
2 Our second prototype corresponds to the second flow. We follow Uber’s original design style but change the operation process. For each step, the user will return to the home page. This prototype is a radical pattern rather than a linear process. After completing all information, an invitation will be sent to the person they invite. The invited person can add their pick up point and the ride will begin.
Compare and contrast
Both prototype serves the same function: pair the user with another user that he/she knows. Also, each user has control on who he/she is going to invite. The invited user can also accept or decline the ride. While enabling the main function to work, two prototypes are still different in ways approaching to it:
Prototype 1 follows the logic of adding a stop in Uber but allows users to pair a new passenger at each stop. In this prototype, user one needs to set both destination and the pickup point for user 2. User 2 can edit his/her pick up point after the ride starts.
Prototype 2 follows the logic of sharing a pool in Uber, and thus allowing each passenger to set their own pickup point. This prototype provides more freedom in user control.
Prototype 1 guides the user to choose a destination, invite friends and choose car type step by step.
Prototype 2 has a tree. It has its home page as the main confirmation page. Users can begin with any option they want to enter first, car type or destination.
User testing - round 1
We conduct user tests to find any usability problems of our two prototype and thus revised and finalized the design into one complete.
As a team of three, we had one person leading the testing process (This could introduce our project to users, or as leading questions to guide users to reflect. etc), one person changes the screen paper after each action of a user, and one person videotaping the whole process.
The tested users include both our friends, strangers, students, and employees.
Point of view
After conducting three groups of user testing, we generate three following principles that we should follow in our design:
• Unnecessary icons and designs really distract the user from what to do. They mislead the users to make a wrong attempt.
• Thus, it is a priority for us to eliminate noises in the design. This would help users to have a clear goal as well as understanding necessary actions to perform to reach the goal.
• Convention has a great power over users. We need to fit our redesign smoothly into the current app, and make it easy to understand. It takes time for users to learn about a new interface and a new function. There is also a greater chance for them to make mistakes.
3 User control
• Users are sensitive about whether they have enough control on the page. They want to lead the system rather than being guided by the system. For example, they want to be able to quit the current page if they want.
• From user testing results, we think it is important to give user 2 more control over setting the pick-up point and quitting the ride if he/she wishes to.
High fidelity prototype
Learning from user testing, users like design that minimize noises on the page, conventionally similar to the original app and enlarge their control to the functions. Thus, we made our prototype based on the second UX flow while revising it thoroughly.
Our high fidelity prototype starts when users open Uber’s home page. The home page shows a map on the top half of the screen like the existing uber home page but has three tabs below to add riders, choose a car type, and set destination. If the user chooses to add a rider from their contacts, Uber will send a notification to the new rider to confirm the trip and enable them to edit their pick up point. After confirmation from all riders, they can begin the trip. When the driver is picking up user1, other users can track the ride through the application, which makes the pick up easier. We chose to make high fidelity prototypes for this design because, from user testing, users reported that this version of the home screen looks more organized and easy to navigate with our new feature. We keep the screens where users set the destination, and choose a ride type the same as Uber’s current design.
Alternatively, we choose to follow Uber’s original flow as a backup. We feel that to make such a huge change of the home page, as what we did in the first prototype, is too bold. Mainly, we redesigned user1’s home page and separate it into different steps, as what Uber does for now.
Unlike the first prototype, we make the alternative screens pretty much as close to Uber’s original home page as possible. We want to make minimum visual changes while approaching the best functional innovation: by simply adding a “Pool friends” option in the riding type list. Thus, the user will still choose the destination at first, then select the ride type while adding a specific rider to his/her journey. This approach might be more efficient because it clearly divides the task into small steps, and our feature appears at a more appropriate place when choosing the ride type. Users will gain control of the company passenger most easily and naturally.
User testing - round 2
We invited three participants and asked for advice after they go through our prototype and the alternative screens. We then concluded several important points that we would take for a change in the final prototype.
Basing on user testing, we have concluded several points that we would improve on in the final prototype.
- We would use the alternative design of the homepage.
1 To clarify and better distinguish user 1 and user 2’s locations on the map, we would have their profile photo marked right above their location point.
2 On user 2’s set up pick up point screen, we would add the destination below the pickup address for users to understand better.
3 Redesign the add rider screen to allow users to add multiple (less than 3) riders at the same time.
4 Redesign the screen that appears after the ride starts, and make it more closely align with the current Uber ride detail screen.
5 Delete the 1 seat option at the Pool friends details page to minimize the confusion about how many persons are added to the trip.
We choose to use our alternative home page flow as the final prototype. From the feedback from user testing and TAs, we decided to follow Uber’s current user flow.
From the first draft, we deleted the 1 seat option in the Pool friends detail page, so that it does not confuse the users about how many seats to choose. Additionally, we added photos of selected riders on the top of the contacts page, so that it clearly shows who is selected.
We also added photos on the map to make it more personalized and shows clearly who is at which stop. For the split fee page, we decided to use the first prototype because Uber does not use any bar representations currently which was in our alternative prototype.
Before and after the story
I have learned a lot during this 3-month project. From our 2 rounds of user tests, I learned that though personally taste of the interface varies, we could find common ground among these users. This is important to keep in mind because the number one goal of a UIUX design is to be user-friendly. It is thus critical to identify helpful feedbacks among those reflections that each user has come up with. As a designer, I shall figure out the real usability suggestions rather than the personal or emotional preference. These are valuable but distracting to the design. My notion is to always remember the object of my design.
Visually, our design looks consistent with Uber's style. I am proud that we made limited changes to Uber's interface while achieving the most effective functional extension.
For future tasks, I will keep collaboratively engaging in the design process and actively looking for critiques or feedback from the users. I will further my visual design skill to advance the delivery efficiently and effectively.