Lyft App Mockup

Lyft App | Case Study


On vacation recently, I tried to split a Lyft ride bill with friends and, in my hurry, found that it wasn’t possible. I later found out there was such a feature, it was just difficult to find! I decided to re-design this feature of the Lyft app to be more easily discoverable and easier to use.


• Current App Research
• User Research

• User Goals
• Use Cases
• Journey Maps

App Research

Lyft & Uber Reviews

Uber and Lyft user reviews

I started first by trying to understand who the user was and what they wanted from the Lyft app by looking for popular issues and problems. Then, I looked for the same things in the Uber app, Lyft’s biggest competitor, while also seeing if there was anything they were doing better than Lyft.


50% – Work/School Commuters
35% – One Time Trip Alone
15% – One Time Trip with Friends

I found the main users as shown above and determined some of the main issues. Most of them had to do with GPS problems, but some of the smaller issues could easily be solved through a re-design of some features, like the “Split Payment” feature.

The current way the Lyft app lets you split rides with friends is through adding their phone numbers, but from a few reviews, I found out that a few users don’t like having to add new contacts or phone numbers just to share a ride with friends. They find it a hassle and end up switching to an app like Venmo or Paypal to split the ride. Based on this, I came up with the idea of adding a username feature with each Lyft account created and an “Add Friends” feature to make splitting rides even easier.

User Research

Based on my findings, I knew my main focus would be on re-designing the feature that lets the user split payments with friends on a ride; however, I also wanted to add an “Add Friends” feature.

User Goals

• Get a ride from point a to point b
• Share a ride with friends
• Enjoy a cheaper ride with strangers from point a to point b
• Easily pay for ride with phone
• Schedule a ride for later
• Arrive at desired location in a timely manner
• Get picked up close to time when ride request was made

Use Cases

• Going from point a to point b alone
• Going from point a to point b with friends

Journey Maps

Add Friends:

  1. Desire to add friend to friend list
  2. Launch Lyft app
  3. Tap button for sidebar expansion
  4. Tap “Find Friends” option
  5. Type friend username into search bar
  6. Tap friend’s name
  7. Tap “Add friend” option (request will be sent)

Ride Booked with Friends:

  1. Decide to book a ride with friends from point a to point b
  2. Launch Lyft app
  3. Type in desired destination
  4. Choose how many riders there will be
  5. Choose which car to take
  6. Choose ‘Split Payment’ option
  7. Type in user names/select friends from list (all must be Lyft account holders) & submit
  8. Approve/deny request sent to each user submitted (each user must deny/approve request before ride is booked? Before ride arrives? If not, user that booked gets charged what was denied)
  9. Sees drive confirmed/driver information
  10. Rides from point a to point b Sees final receipt


I sketched out the “Add Friends” feature and the new “Split Payment” feature; however, I decided to only move forward with the main feature of splitting ride payments with friends due to my time constraint.


Many parts of the Lyft app I felt were still user-friendly (like the layout of the app with a map on the top of the screen and information/options at the bottom) so I kept those aspects in my sketches and added in my own thoughts of re-design alongside those.


I tested out the sketches on three users, two of which had used the Lyft app before and one who had used a similar app, Uber. I found that most of the process made sense to the user; however, there were a couple of parts that needed to be changed before I started on high fidelity.


1. The screen informing the user that they will be charged the cost of whatever request is denied was completely passed over.

• The first user immediately tapped the “Confirm Lyft” button without reading the disclaimer.
• The second user scanned over the text, but didn’t tap “I understand” before tapping “Confirm Lyft.”
• And the third user scanned over the text, hit both of the subsequent buttons, they asked why the screen was apart of the process.

I concluded that the last screen had valuable information for the user, but was presented in a bad way. The screen was seen as a hassle or was completely looked over, making it just one more button for the user to press without a purpose behind it.

2. The screen that has the user choose how they will pay (split payment or pay in full) was confusing for the users. With one option saying split payment and the other showing their saved card information, the users thought that the split payment option was the only option. It seemed like the second option was only showing them the card the app had on file that it would charge for split payment.

I knew this screen needed to be changed to be more clear about the payment options the user has.

High Fidelity

I took these issues into consideration as I moved onto high fidelity and made changes to make the functions clearer and more purposeful.

1. The disclaimer issue was tricky to solve because I knew it needed to be shown after the user had already passed the “Choose Payment” screen, but before they confirmed the ride. I considered a pop-up once the user tapped “Split Payment”, I thought about keeping a screen similar to the sketch, and I considered having it appear on the “Split Payment” screen, but each option seemed like it would be annoying to the user or slow down the process. In the end, I decided the best option would be to have it on the screen that gave the user all the ride details. The screen would look as it normally does, giving the user details about the ride, and the number of passengers, and so forth, but there would be an added area informing the user of the disclaimer.

2. I addressed the issue of the choose payment screen appearing to only have one option (split payment) by adding the “Pay Full” option instead of having the user’s card information there. I moved the card information to the screen that allows the user to choose friends to split the ride with. This made the Lyft ride reservation process more efficient because the user can choose friends to split the ride with, choose the card to pay with, and confirm the payment all in one screen.


In the end, I was able to get a working prototype for the “Split Payment” feature and fix some issues that had come up in user testing. I hope with this new design and feature that splitting Lyft rides with friends can be easier and quicker. Due to my time constraint, I wasn’t able to get a high fidelity for the “Add Friends” feature.

Some things I learned from this project were:
• test as much as possible
• don’t get too attached to a design or idea because it’s probably going to change
• understand the user and what they need from the app before even thinking about designing