Lyft Rating System

Lyft is one of the world’s largest transportation companies, facilitating over one million rides per day in up to 300 US cities, despite owning no fleet of vehicles. One of the most important aspects of Lyft’s service is the qualified and accurate ratings from users, although the current five-star system’s limitations tacitly encourage users to rank their driver using only very good or very bad rankings. Our goal was to create a replacement for the current rating system that Lyft uses, considering the ways various rating systems constrain the input of users, the ease of use in urban environments, and the ways in which this information could be used maliciously against drivers.

Jump To Project Stage

While I was involved to some degree in the majority of activities throughout the project process, there were certain elements that I took the lead on.

Key Responsibilities

1. Conducted unstructured interviews with Lyft & Uber drivers during rides.

2. Created user personas and scenarios.

3. Designed and refined low/mid-fidelity prototype UIs for testing purposes.

4. Conducted two rounds of usability testing with paper prototypes, with eight participants.

5. Designed proposed solution UI for final project presentation.

Our initial secondary research consisted of gaining an overview of the issues with the current system, and rideshare environment in general for all Lyft stakeholders, with mediums studied including Twitter & Facebook through keyword and hashtag searches, academic and public reports as to the emotional invocations of a five-star system, and YouTube videos depicting drivers frustrated with the current system. We also identified other rating systems, evaluating their strengths and weaknesses in the contexts of some examples of their implementations.

Key Research Topics

1. Evaluating the 5-star rating system, it's strengths and weaknesses.

2. Alternative forms of rating systems, such as the thumbs up/down, and linear scales.

3. Social media posts regarding positive and negative experiences using Lyft and Uber.

Using the findings of the initial secondary research, we conducted semi-structured interviews with 8 users of Lyft or Uber, to gather more information as to their rideshare usage behaviors, as well as their rating habits and understanding of the system currently in place. I also took two separate rides with a driver for Lyft, and then a driver for Uber, engaging in unstructured, free-flowing conversation to gain their perspective on the five-star rating system incorporated by both companies, and also to gain some understanding of how Lyft works, being an avid Uber user myself.

With our core research phase complete, the team conducted an affinity diagramming session. Each team member sifted through all of the research carried out to date, and for around 30 minutes wrote down each separate point raised on to its own sticky note, dispersing all of the sticky notes randomly on a whiteboard. The team then worked together to group all of the sticky notes created into associative groups, to identify key and reoccurring patterns and trends, in terms of problems found, user attitudes as well as behaviors, and strengths of alternative rating systems used in other applications.

The trends and patterns presented in the affinity diagram allowed us to identify the dominant problems caused by the current system, that would outline the focus of our succeeding research and design process.

Problems

1. A "good ride" is completely subjective, with most users only rating 1 or 5 stars, causing inaccurate ratings for a variety of reasons.

2. The current system places too much pressure on drivers. Anything below a 5-star rating can severely damage a driver's rating.

3. Many users are not currently compelled to rate their drivers, deeming it to have little or no effect on their future experience.

4. The star system does not allow users to quickly and accurately recall and distinguish their ride quality through a rating.

Streamlined Personas

Based on the findings of the secondary and primary research so far, we were able to create three user personas to accurately represent the needs required to be addressed in the ideation and design of a solution, incorporating two representational passengers and a driver.

Initial Design & Team Evaluation

Moving into the design phase of the project, each team member went away to individually conceptualize and sketch some ideas for solutions to the problems raised throughout the research phase. As a team, we then discussed each other’s proposals, identifying the promising qualities that could be taken forward from each design. After collaborating to sketch out a solution based on the qualities identified, I then used Sketch to create a digital version of the design, which we then critiqued as a team to identify aspects of the design to be fixed prior to our first round of testing with users.

Design Iteration & First Round Tests

It was at this stage that the team decided to move in a slightly different direction and extend the scope of the project, to create a system that would directly allow users to tailor their ride taken through pre-selecting preferences, and a driver being found who would ideally closely match those preferences. Taking these design changes into account in the design iteration, we conducted our first round of testing with users.

Using a paper prototype, the four participants recruited were given the scenario of a user who had just had a ride that matched some of the preferences selected, but was not necessarily fantastic or terrible. With one facilitator giving the scenario and then acting as the ‘computer’ manipulating the paper prototype dependent on user actions, we were able to gain valuable insights through observations, and asking the participant to incorporate a think-aloud protocol, but only requesting free-flowing thoughts as to not increase cognitive load.

With the constraints placed upon the project in terms of time with the ever-looming deadline for the class project, some minor modifications were made to the design based on the feedback given in the second round of testing.

Jump To Solution Section