Seattle Yellow Cab app redesign

A conceptual design project

 

Role: User Researcher and Project Manager

Duration: 2 weeks

Programs used: Keynote, InVision

Skills used: User interviewing, usability testing, communication, project planing and management, storyboarding, design communication

Team members: Eve Lalonde (visual designer and information architect) and Aimable Nkurayija (interaction designer)

Background

 

With the advent of Uber and Lyft, taxi use has dropped considerably. To stay competitive, the Seattle Yellow Cab app must improve to meet user expectations at a time when Uber and Lyft have set the industry standard. 

My role on this project was user research. Below are highlights and key findings from my research. My full research report can be found here. 

Research Phase

Initial Exploration

 

I started my exploration by downloading the Seattle Yellow Cab app and clicking around. The user is presented with a list, and when you click a list item, the app asks if you want to create an account, or do it later. However, doing it later isn't really an option, with the app prompting the same thing every time you click. The menu is a slide out menu with Track, Rate, Pending Bookings, Completed Bookings, My Profile, Terms of Service, and More Info.  There is a “Cab Hailer” option that didn’t seem to work, though I’m not sure what it would do if it were. When clicked, it redirects to a page with four large zeros displayed, stating, “Your assigned number will show here after a cab has been assigned to you.  Use the cab hailer to assist in connecting with your driver.”

Contextual Inquiry

 

On June 11th at beginning at 9:42pm, I observed a user use the Seattle Yellow Cab app to call a cab. You can find my notes and observations here. Following the ride, the user reflected on his statement.

User thoughts:

Overall, the app was clunky to use. It wasn’t clear what the options meant. The first time the user went through it, he didn’t feel like it was the right way, so he started over. Then, he thought he might have messed up and double booked.

“Overall, it made me feel stupid, and made me doubt that I was ever going to get a cab, and, uh, and made me not really want to take cabs using the app anymore.”

Key Findings

  • The "optional" not optional account creation is confusing.

  • The map isn't interactive, and doesn't allow pin drops for setting location. It’s become a standard, and the user tried to do this but the feature didn’t exist.

  • Had to determine address from the street corner

  • Booking confirmation not as clear as it should be.

  • Many buttons and labels didn’t clearly describe what it did or was for.

  • User didn’t seem to be able to track the cab coming to ge him

  • Colors for taxi icons had no legend. Unclear what it meant.

  • Fare rates very difficult to find.

  • User looked at the map to look for his taxi ad the language and buttons were the same as if he hadn’t booked anything.

  • Took 19 minutes to get through this process. User “felt stupid”

Business Analysis

 

After inspecting the app, I performed a business analysis and a competitive analysis to get a sense of what the business needs might be and what competition exists in the industry. This background is important to know throughout a project to be able to balance user and business needs, and having this knowledge prior to user interviews gave me a broader knowledge base to write questions from.

Seattle Yellow Cab makes money driving people from place to place. In order for them to do business, customers/users must be able to call a cab, provide pickup and dropoff location, give name and contact details, and pay upon reaching their destination. Currently, several aspects of the app make this difficult.

The map doesn’t assist in setting locations. Completing the booking process is time consuming and frustrating, causing some to abandon the task. Customer reviews indicate that their credit card readers sometimes fail.

I have yet to get any actual numbers to base a specific metric on, but lowering the number of cancelled bookings would be an excellent and fitting goal. Without having access to data, I’d guess at least 5 people cancel/don’t complete a cab booking daily due to app uncertainty or frustration. This conservative estimate is 150 cancellations or abandoned bookings monthly. A successful redesign would decrease this number by at least 30%, or 45 fewer cancellations/incompletes monthly.

 
Seattle+Transportation+Distribution.png
 

Image by the Seattle Times

 

Competitive Analysis

 

Competing businesses in the area are Lyft, Uber, Orange Cab, and the public transit system.

Lyft:

A popular app for driving service. Traditional cab style, carpooling, vans, luxury cars, black cars and SUV options available. The map shows you the location of nearby cars, with estimates for pickup times. Prices are shown in advance. You pay through the app, and rate the driver at the end.

Uber:

A popular app for driving service. Traditional, individual cab style, carpooling/ridesharing, and luxury car options available. The map shows you the location of nearby cars, with estimates for pickup times. Prices are shown in advance. You pay through the app, and rate the driver at the end.

Orange Cab:

Another taxi service in Seattle. Quite similar to Seattle Yellow Cab. Their rates are the same. Orange cab offers child car seats, accessible vehicles, and pet friendly vehicles. You can book by phone or by app. Payment in done in person at the end of the ride.

King County Metro:

Seattle public transit system. Buses, commuter trains, light rail, streetcar, and ferry. Quickest way to pay is with an orca card. Fares vary by zones and time of day.

image-asset.png
 

Key Findings

  • Other apps (Excluding King County Metro, but including orange cab) have better driver tracking, let you select locations from the map, and show cost estimates before booking. Users want these and the competitors have them.

  • Worst visual design of all.

User Interviews

 

I interviewed 5 people, all of whom have taken taxis, but now prefer to use Lyft or Uber. You can read each interview summary here. 

Key Findings

  • Most users want to know the cost (or an estimate) before booking.

  • Some users prefer paying in the car, while others prefer paying through an app.

  • Transparency in pricing is important to users.

  • Tracking your cab is universally liked and expected.

  • A majority of users expressed that taxis are a second choice to uber/lyft.

  • Driver rating gives even more power to the user.

App Store Reviews

 

Because the Seattle Yellow Cab app already exists on the app store, I was able to get a large amount of user feedback.  Overwhelmingly, people had used it once or twice, and then posted about how frustrating it was, saying they would not use it again. 

Reviews included comments such as "Save your time and just use Uber," "I decided to use it after Lyft and it was a mistake,"  and "Fire your UX designer".

Persona Creation

 

Based on user research, I created Sara Olsen.  All of her needs and pain points are taken directly from things users said in interviews.

Like the users I've talked too, she has taken taxis in the past, but now prefers Uber and Lyft. She isn't opposed to taking a taxi, but Uber and Lyft are just a lot easier. 

IMG_3726+2.jpg
 

Storyboard

In this scenario, Sara is out with friends at a bar in Ballard. As the night ends, she needs to get home to West Seattle. When she opens Lyft to call a car, she sees that it’s Prime Time pricing, with prices almost twice as high as usual. When she checks Uber, it’s the same. Unwilling to pay twice what she usually does, Sara decides to try out the Seattle Yellow Cab app she downloaded a few weeks ago. She opens it up and sees several nearby cabs. Seeing that their cost is by the mile and is always fixed, she quickly enters her contact and payment info, and requests a ride. A few minutes later, she gets picked up and is on her way home. When she arrives, she pays the lower-than-expected fare on her phone, and exits the car.

Defining the Project

Scope

 

As a group, we decided that our project scope would be a redesign of the booking (and riding) process. Profile creation, history, payment info, and other non-booking/riding section is out of our scope. 

After deciding on our scope, I created the following problem and solution statement: 

Problem:

With the advent of Uber and Lyft, taxi use has dropped considerably. The Seattle Yellow Cab app lacks many features users expect. Out of frustration, users often abandon or cancel their booking, and instead use Lyft or Uber.

By focusing on improving or adding these features, users will be happier with the booking process, and will be less likely to abandon or cancel their bookings.

Solution:

Uber and Lyft have set user expectations for ride calling apps. To meet user expectations we will add a cost estimate based on mileage and the ability to rate drivers. We will also increase the functionality of the map, allowing users to see their cab approaching, and set locations by dropping a pin..

Features

 

As a group, we came up with a list of possible features to include in the app. We organized them in a feature prioritization matrix to help us figure out visually where our ideas sit in terms of importance and feasibility. Based on their placement, we then moved them into a numbered list, eliminating the bottom 2 features, with the ability to work our way up as budget constrained.

IMG_6606.jpg
 

Prioritized Features:

  • Fare estimate

  • Pin drop

  • Driver route

  • Show cab on map

  • Passenger meter

  • Showing nearby cabs

  • Cab number

  • Wheelchair accessible

  • Show movement on map

  • Logo change

  • Better CTA and labels

  • Tab not hamburger

  • Driver photos

  • Ability to rate/tip

  • Hail without destination

  • In app competitor compare

Design, Test, Iterate

IMG_9234.jpeg
 

With features in mind, we whiteboarded and sketched a few screens as a group, and then our interaction designer did further sketching and paper prototyping.

Paper Prototype Testing

 

Our interaction designer started sketching, and after he completed paper prototypes, I tested them with 5 users.

Test Scenario

You are calling a car to take you home from some drinks with friends. You usually take lyft, but when you open the app, you see it’s busy and prices are super high. You remember that taxis have fixed fees, that never change, so you decide to try Seattle Yellow Cab.

  1. How would you use this app to get home?

  2. You liked the app last night, so you decide to use it again. Tomorrow morning at 6 am you have to leave for the airport. You don’t want to have to call in the morning, so you decide to schedule a pickup.

  3. You’ve just gotten back from a short vacation. You are still at the airport, and want to go home. You use the Seattle Yellow Cab app again, where your address is one of your “favorite” locations.

  4. You and your grandma are going to lunch. Your car is too small for her wheelchair, so you decide to request a wheelchair accessible taxi.

Findings

In those tests, users indicated that the Wheelchair accessible van was confusing - either because it was an icon with no label, or because it was a large call to action which didn’t seem like it was really part of the main booking process. They were also unsure what the clock icon for scheduling rides in advance was for. They also weren’t sure what might be contained in the “my routes” tab.

Based on the findings, we made 3 changes on our next iteration:

  1. Made the wheelchair accessible van option a labeled button

  2. Created a labeled button for scheduling a ride

  3. Changed the tab name from “my routes” to “routes”

Lo-fi Testing

 
 

Our interaction designer created wireframes in Sketch, and then uploaded them to InVision. 

For this round of usability testing, I used the same scenario and test questions, since that is what our user and persona would be doing on the app. This time I tested 6 users. 

Findings

Problem:  Users are confused about the Accessible Vehicle, because it looks the same as buttons that load a new page, but is just a yes or no. 

Solution: make it a toggle

Problem: Users aren't sure if "pick me up here" means the app has their location or not.

Solution: Change to "current location"

Problem: Users assume the competitor cost estimates are not estimates, but accurate. 

Solution: Change wording to be clear that they are estimates.

Problem: Users thought "Ride with us?" on the confirmation page had something to do with ridesharing.

Solution: Change the language to be "confirm pickup"

Hi-Fi Testing

 
 

After testing with the wireframes, our visual designer made hi-fi screens with visual design flair based on the discussed problems and design changes from the previous stage. 

We did another round of testing with these screens in InVision, with 3 people.

The two big issues that came up were both with the cost comparing modal. Users felt like they had no choice but to confirm pickup. The text inside the modal was the other problem. Currently, yellow cab’s name and price blend in with the others, and users still don't understand ~why~ they are seeing the list. 

Next Steps…

 

If we had more time, we would have iterated gain, and tested again. 

Specifically, we would redesign the competitor cost modal, so that the user has an option to cancel as well as confirm. We would also redesign the text to emphasize the benefit of Seattle Yellow Cab. (After consulting with a lawyer on the legality of the in-app comparison.)