Overview
This summer I interned as a product designer at the ridesharing company, Lyft. I worked on the Trip Experience team which focuses on the core flow of taking a Lyft from selecting a pickup spot to ending a ride.
While on the team, I was the lead designer for developing an experience for both riders and drivers to call each other within the app. Throughout my project, I collaborated with cross-functional team members like software engineers, user researchers, and product managers to determine major design decisions. Throughout the design process, I conducted a competitive analysis, created multiple design interactions, developed prototypes, and conducted user testing, analysis, and synthesis.
Timeline
8 Weeks
Role
Lead designer
Tools used
Figma
Problem
One of the most painful parts of driver-rider communication is missed calls. The Trip Experience team has worked on a small experiment (Missed Call toast) and larger features (Ride Chat) to mitigate this issue, but they have yet to invest in VOIP, or in-app calling. With that in mind, the question I wanted to answer is how might I reduce missed calls by extending in-app communication to address phone calls?
Goal
Create an experience for both riders and drivers to communicate effectively before the pickup.
Understanding the problem
To understand the problem better, I asked myself the following questions:
Why is this problem important to solve?
I learned that missed calls are detrimental to the point of being integrated into NES (Negative Experience Score), showing that it is tied to decreased long term retention. There is an in-app chat feature within the app to help drivers and riders communicate, however, it doesn’t solve all the problems. A quarter of text-initiated communications ends up having a phone call anyway, suggesting that in-app calls are a more effective way to communicate.
In-app chat
What is causing the problem?
Currently, when a rider gets a call from a driver, that call comes from an unknown number. With the rider being unsure who is calling them, they dismiss the call thinking that it’s spam. When looking at the data, 15% of drivers' calls to riders go unanswered.
Who is affected by this problem?
Currently, Lyft’s target demographic is low to mid-income men and women from ages 18 - 35. These riders are interested in using Lyft because Lyft provides them the freedom from the stresses of driving, parking, and navigating.
Research
After getting a better understanding of the problem, I looked into what makes this potential in-app call feature so special. I learned that in order for in-app calling to work, it has to use VoIP, also known as Voice over Internet Protocol. VoIP allows users to make calls over the internet instead of using their cellular data. VoIP calls are extremely common with it being used by apps like Facebook, Instagram, Google Hangouts and more.
Some of the benefits of using VoIP are:
• VoIP calls are either free or cheaper than cellular calls. As long as you have an internet connection, a VoIP call is free.
• VoIP calls are private and secure. Since a VoIP call is done over the internet, your personal number isn’t being shared which gives you privacy and security.
Competitive analysis
After researching VoIP calls, I took a deep dive into what other companies are using VoIP calls to understand how they’re being used effectively and also keep in mind usability issues to avoid. Below is a snippet of the analysis conducted; if you are interested in viewing the full analysis, click here.
Competitive analysis
Competitive analysis learnings
A common thing I noticed when doing the competitive analysis is that when a user receives a call, the call takes up the entire screen. I did some research into why that is the case and I learned that unlike messages, phone calls benefit from an immediate decision (to answer or ignore), so an intrusive ‘notification’ with as much info as possible is warranted, especially when sounds can be disabled: you get a number, a name, a picture, if possible (and these are all details you have curated with direct relationship to their importance).
Android and iOS VoIP calls
Design explorations
With the competitive analysis in mind, I began some design explorations.
In-app call prompts
With in-app calls being a new option available to users, I thought it would be a good idea to prompt riders to select an in-app call instead of their cellular data since in-app calls are free for riders. I explored a few options shown below. I liked that the copy made it clear that the riders’ number wouldn’t be used, but it wasn’t made clear that the call is free. I wanted to address that before I put out a final version to go through user testing.
in-app prompt explorations
Accessibility prompts
I kept in mind that phone calls aren’t always the best way for drivers to communicate. There are drivers that are hard of hearing who would much rather communicate over chat than over the phone. To make sure users are inclined to send a message during these cases, I created a prompt that lets users know that their driver is deaf or hard of hearing. I liked that the copy made it clear to users that they should send a message instead of calling, however, I learned that not all drivers like to disclose that they are deaf or hard of hearing. There have been instances where users cancel a ride after learning that information about their driver. With that in mind, I wanted to address that issue with a new design iteration before I conducted user testing.
Hard of hearing prompt explorations
Full-screen component
I did a few iterations of what happens when a user selects the call in-app button. For these screens, when a user selects the phone icon on the top right, the entire screen is taken over by the call. The rider can mute the call, put the call on speakerphone, or end the call. In addition, the screen is transparent so that users can see that they can return to the chat screen or go back to the map if they select the back arrow. When working on these screens, I came to realize that having a call take up the entire screen makes locating the driver more difficult. If a rider gets a call that takes up the entire screen, they have to minimize the call, go back to the Lyft app, and then look for their driver. Those additional steps create a lot of friction, so I thought of ways to get rid of that issue.
Full-screen call
Minimized call component
To find a way around full-screen calls, I explored the idea of having a minimized call component. This component would allow users to multitask while on a call including looking at where their driver is going to as well as edit their ride if needed.
With the first iteration, I used a toast to communicate when a rider is receiving or in the middle of a call. However, the problem with toasts is that they are only on the screen for a few seconds, so when the toast disappears, a rider can no longer interact with the call.
With the second iteration, I explored the idea of using a banner since it would be permanent on the screen. However, the banner lacked information like an image and context letting the user know that they can expand the call. In addition, I learned that banners can only be used to display connectivity issues, so using a banner in this way was not appropriate.
For the third and fourth iterations, I created a new minimized call component and explored the different information displayed on the component. With both components, I didn’t feel as if they clearly communicated the idea that the driver had contacted them or that they were on a call so I worked on a few other iterations before I settled on a final one to be used during user testing.
Minimized call component
User testing
Here are the final designs tested:
In-app call prompt
For this final iteration, I worked with a UX writer to rephrase the copy so that it communicated the two main value propositions for using an in-app call which is that it’s free and that the riders’ number won’t be shared.
Driver prefers messaging prompt
To address the issue of drivers that are hard of hearing without disclosing their disability, I worked with a UX writer to change the copy from “Driver may be hard of hearing” to “Driver prefers messaging” to incline users to send a message instead of calling.
Outgoing calls
Once the user selects the phone icon in the chat screen, a minimized call component will drop down. With the component, the user has the option to either put the call on speaker or end the call. If the user wants to go back to the map to see where their driver is headed to or edit their ride, they can select the exit icon and return to the map.
Incoming calls
Similarly to outgoing calls, when the rider receives an incoming call, a minimized call component will drop down. The rider has the option to answer or decline the call. If answered, the rider can put the call on speaker, end the call, and edit their ride.
Incoming call image comparisons
Before I conducted user testing, I created red/green answer call and decline buttons as well as white/green buttons for incoming calls. I did this because I wanted to know if people who happened to have red/green color blindness or complete color blindness had an issue with distinguishing the red/green buttons and would instead prefer the white/green buttons.
Incoming call comparison images
User testing methodology
I partnered with a UX researcher and used usertesting.com to run unmoderated, remote tests with 3 figma prototypes of a “golden path” - the ideal path I wanted users to take. I also used the image comparison to understand preferences between the answer call and decline buttons.
Demographics
• Age: 19 - 50
• Mix of African American, Asian, Hispanic, White
• From all over the U.S.
• 1 red/green colorblind
• 1 completely colorblind
Was my hypothesis validated?
Hypothesis 1
The copy on the prompts will incline users to make an in-app call
✅Validated
Positives
• All participants decided to make an in-app call.
Negative
• Only half the users understood that making an in-app call means that their number will not be shared.
Hypothesis 2
Displaying a minimized call will make it easier for riders to communicate with drivers
🤔Inconclusive
Positives
• Users like the ability to multitask while on a call.
Negatives
• Call component was hard to notice. Users commented that the component faded into the background.
• Call component was hard to reach with one hand. A user commented that in order to interact with the call component, they would have to hold the phone in one hand and use the other hand to reach the component.
• Call component didn’t follow users’ mental models. Users commented that they were used to having a call take up the entire screen.
Hypothesis 3
Riders will prefer the red/green answer and decline buttons over the white/green buttons
✅Validated
Positives
• Overall, all six participants, preferred the red/green answer and decline buttons.
• Many users commented that they are used to seeing the red/green combination on the other applications that they use.
• Both users who either have red/green color blindness or complete color blindness said that the shades on each button were distinct enough to tell the difference.
Additional learnings
Map
• Most users didn’t think it was an issue not being able to see the map while on the chat screen.
• All users understood that tapping the X would take them back to the map.
Although navigating to the map isn’t an issue for users, I would like to do a usability comparison between having a chat without the map and a chat with the map.
Speakerphone
• All users were easily able to recognize the speaker icon.
• A couple of users mentioned that they like that they can place the phone on speaker and look at the map.
• A couple of users commented that they don’t find the speakerphone necessary if they’re in public.
In conclusion, the speakerphone is a useful addition to the component.
• Some users may not find it appropriate to use at times, but that is up to their own discretion.
Takeaways and next steps
After finding such insightful learnings, I asked myself the following questions on how I can improve this feature:
How might I differentiate in-app calls vs. data calls?
Idea 1
Rewire the copy. I can try to make the prompt clearer by further explaining that in-app calls use wifi instead of cellular data.
Idea 2
Add an info icon. With an info icon, users can tap to find out more detail about the difference between each button.
Idea 3
Remove the prompt all together. With this option, a user will be thrown into either an in-app call or cellular call depending on their internet connection.
How might I make outgoing calls more noticeable?
Idea 1
Enlarge the component with the option to enter a full screen mode. The call component will be almost double the size of the original. If preferred, users can tap the call component to enlarge the screen and minimize it again if interested.
Idea 2
Enlarge the component without the option to enter a full screen mode. The call component will be almost double the size of the original. Users will only be able to see a minimized call.
How can I make incoming calls more noticeable?
Idea 1
Full-screen incoming call with the option to minimize. When users first receive a call, it will take up the entire screen and if they are interested in something like viewing the location of their driver or editing their ride, they can minimize the screen and do so. The component will almost double the size of the original and appear lower on the screen so that it’s easier to reach with one hand.
Idea 2
Minimize the incoming call. The call component will remain minimized, but almost double the size as the original component. The component will also appear lower on the screen so that it’s easier to reach with one hand.
How might I design for edge cases?
Ideally everything will go right when a call happens, but there will also be cases where things go wrong. So It’s important that I consider what the design looks like when a call ends, when a driver is unavailable, when a call fails, and when there’s a connectivity issue.
How might I design for permission access?
When a user selects the in-app call option for the first time, Lyft will need access to their microphone in order for the call to happen. I have to consider how I might make sure that information is clear to the user.
What I would do differently
Ask more specific questions
I noticed during user testing when a user answered a question, I had even more questions that I wanted to ask them. If I could go back to do another test, I would sit down and think about all the possible questions that I want to be answered.
Provide more image comparisons
When it comes to the chat screen, I wish I did an image comparison of a chat screen with the map and without the map to see if users had a preference one way or the other.
Conclusion
I had a great internship experience while at Lyft. The hardest part was putting a usual 12-week internship into 8 weeks and making the most out of it. I think the biggest thing I learned is there's not really a right or wrong design process. While interning, I saw that everyone goes about solving problems differently and that what really matters at the end of the day is that you are able to come up with impactful solutions.
