Exploring alternative Lyft app experience

I love how Lyft has simplified my daily commute and changed my intra-city travel behavior. Last week while I requested for a ride and waited for the car to show up, my designer instinct kicked in and I started wondering how the app was designed the way it was designed and what other solutions, flows or patterns could the design team have explored before settling on what we see right now. This made me curious and I spent a rainy Seattle weekend exploring alternative ways of interacting with the app.

Before I begin, we must know that there is a very good chance that the design team would have considered these explorations and might not have implemented because of various UX/business reasons which is not publicly available.

Ideally a project like this would be informed by data from the research and usability studies, usage analytics and user feedback. I showed some of my early sketches and wireframes to my colleagues to get a general idea before working on the app over the weekend. Since this exercise isn’t affecting any users, I went ahead with the assumptions.

Current Homepage Experience

When the app is opened, before requesting for a ride, we see the screen shown below. The car selection modal is open by default. The modal, along with the address bar and the primary CTA occupy 48% of the map space.

48% of the map space covered

When the modal is closed, it reveals a significant portion of the map with only 18% of the map being covered in the bottom half. However, the car information (i.e the number of seats and duration) that is in the modal are no longer visible when it is collapsed.

18% of the map space covered

Research

I ran a short informal interview with my colleagues at work to get a sense of how they were using the app and what they thought of the existing layout. What I learned was:

  • Having a map based interface, it’s important for a users to see their location on the map.
  • Users do not frequently change the type of car.

Alternative Homepage Design

With some rough sketches, I came up with a few early ideas. I put the wireframes in front of my colleagues and observed them using it. People mentioned that they were comfortable with the existing interface for the most part, except that they said they wished to see their location clearly on the map.

Based on these findings, I came up with a design goal:

Allow users to select a car type without reducing the map space on the screen.

By moving the car selection out of the address field into it’s own separate bar we get an additional 22% of the map screen space. The wider car-type selector accommodates car-related information & selecting other car types without having to open the modal. This design change provides 3 benefits while taking up only 8% of additional screen space.

Users can click on the car and it opens the modal as it does in the current app. The modal has been made larger to keep it’s size consistent with the bar it expands from.

Different car types can be selected

Hypothesis: By keeping the modal collapsed by default, a user gets to see a larger map upon opening the app. This avoids having a user’s location hidden behind the modal if they happen to be situated in such a position when the app is opened.

The modal has two buttons at the bottom — a collapse button & a ‘My location’ button. The location button functions as a substitute to the default ‘My location’ button which gets hidden when the modal is open.

The ‘Users’ location’ button is kept within the car-selection modal to maintains the consistency of the button position. It also affords easier recognition and stays consistent with users’ expectations since the button exists in the same position in the current app, when the modal is open.

Risks

The new design now occupies slightly higher percentage of map space when the car-type modal is collapsed — 26% as compared to 18% in the current design. It also occupies more space when the modal is open.

Keeping the ‘My location’ button within the car selection modal might introduce confusion in a user’s expectation of what that button might do in the given context. Alternative position for the button was explored as highlighted below, but its location is ergonomically inconvenient and users with tall phones might find it hard for a single-handed operation.

Hard to reach ‘My Location’

Other Designs Explored

  1. The concept below explores positioning the CTA button along with the address bar. The car selection modal sits below this group making it more accessible for a single-handed use. This increases the map space usage to 82% along with the swipeable car-type selector.
Reduces map space encroachment, and includes the swipe-able car selection pattern

However, this pattern doesn’t perform well when there is a longer text in the CTA button as seen below.

Set Dest…Oops

2. This concept combines the three functions, i.e selecting car-type, address bar and ’Set Pickup’ CTA, into a single unit. The CTA button label is replaced by an arrow which takes a user to the next step. This pattern has the best use of map space, however, without a label, it would be hard for a user to know what this button does. Also the destination page was beyond the scope for this project and I did not explore the next steps for this version.

One bar to rule ’em all!

Profile Page

The current app has a minimal user profile page with most of the app functions being present in the drawer menu. Also, clicking on the avatar icon in the homepage opens the navigation drawer which is traditionally done using a hamburger icon.

Alternative Profile Page Design

Design Goal: Design a profile page that contains all the necessary functions & information a user needs.

I created a unified experience which contains a user’s profile and also the important menu items in the same page. I designed two versions of the profile page with minor changes in the content, button positions & visual design.

Alternative profile page design

Adding an alias

Hypothesis: Drivers usually find it hard to pronounce names that are long and culturally different. A user’s name is taken from his/her Facebook profile and currently the name cannot be changed. Providing a way to add an alias allows a user to set the name they prefer to be called or one that’s easier to pronounce.

The ‘Add alias’ link affords a user to click on it and set an alias. The modal dialog was chosen since there is only one action to be taken.

Adding an alias makes it easy for drivers to say hard names (like the author’s name)

Alternatively, this action can also be completed in the edit profile page.

Running an A/B test & studying the use frequency of the alias option would confirm which pattern works best for the users.

Adding alias in the settings page

Profile Page Version 2

Exploring an alternative visual, content & layout design.

What I would do if I had more time/resources?

In a work setting, the next thing I would do is to get some peer feedback on the designs to understand their perspectives & consider any ideas that they might have.

After that, the next step would be to test the hypothesis with real users. This is done by building a functional prototype using tools like Framer or Invision and creating a usability study plan that describes the goal of the study, user tasks, success metrics, interview questions & participant profiles. Running the study with 6–8 users usually uncovers 80% of the usability issues.

The success or failure of the design can be measured by analyzing quantitive findings like time on task, success rate, SUS scores etc and qualitative findings like interviews, user quotes and by observing non-verbal feedback. Based on the feedback and study findings I would iterate on the designs that didn’t work for users and run more tests until all the issues are satisfactorily resolved.

The final step would be to create high-fidelity mock-ups and redline the designs using tools like Zeplin before sending them to the dev team for turning the designs into code.

While this is a general process, every design project is unique and the testing & iteration process will vary depending on the user goals, business goals & development schedule.

You made it!

If you made it till here, you’re awesome! I’d love to hear your thoughts and feedback on this exercise. Thank you!