Product Design Misteaks: UberEats

What’s worse than getting no user feedback?

Recently I’ve started driving for Uber while applying for Product roles in Seattle (looking at you recruiters) a company which i’ve been a fan-boy of for years. The pay is pretty decent, and i’ve met some fascinating people. They even offer a leasing program, Xchange, where you can pay off a car through driving (I have some opinions about leasing through Uber Xchange vs. traditional leasing I will reserve for another post).

Uber is a company that iterates incredibly quickly and experiments often. Because of that, they rely heavily on data from both drivers and passengers to improve their product offerings.

Once you’ve been driving successfully (receiving 5 star ratings) you become instantly eligible for UberEats. There is no instructional video you are forced to watch, you just suddenly start getting food delivery requests.

From the Driver’s perspective the UberEats experience is as follows:

1) You receive a request to pick up food at a local restaurant.

2) After accepting the trip, you navigate to the restaurant.

3) Parking: Arriving at the restaurant, you need to find a place to park your car temporarily, and if there is nowhere to park (which is often the case downtown) you must put your hazards on and quickly run into the restaurant to retrieve the food.

4) Wait #1: Entering the restaurant, you provide the host/cashier with your food order number and the name of the purchaser. You then have to anxiously wait for the food while your car idles outside in some precarious spot with the hazards on.

5) After confirming everything is in the bag, you are then given the location of the drop off point.

6) Wait #2: When you arrive at the drop off point the customer usually comes down to meet you as you arrive. Sometimes they write the suite number or apartment number, and the driver is supposed to go and deliver it to the door. If the that is not the case, the driver must either:

1. Go inside and leave it with the concierge / desk attendant.
2. Sit in your car and wait for the person to come.
3. If there is an apt or door number included, you can go all the way to their door and deliver the food.

Major Customer Experience Flaw: Unlike UberX when delivering UberEats, you are not provided with the customer’s number (the customer has the driver’s number however). There may be a reason for Uber not providing the number (protecting customer anonymity?), but this seems rather odd since, as a customer and a driver, having the contact information is undoubtedly the best way to resolve uncertainly in the scenario where you cannot get inside the building and the person receiving the food does not call the driver. Otherwise the driver has to leave the food somewhere on the front steps because there is no number to reach the customer with, and the driver is losing money by waiting around.

But this is not the point of this blog post. Here’s the kicker.

7) After confirming the successful delivery, drivers are prompted for feedback about the “rush_rating_dropoff_description”, a vague (even for a programmer) thumbs up or down which is presumably asking the driver whether or not the driver was fast in their delivery? … or maybe its asking whether or not the restaurant was fast enough in delivering the food? … or maybe its asking whether or not the customer took a long time to meet you?

What is worse than getting no user feedback?

Getting false feedback, or unclear feedback. What does it mean when someone presses a thumbs down? Whose failure was it? What is one part of the process was fast and another was slow? What can you actually do with this information? Think of the massive amount of rich information that is wasted because the question was framed too generally. This is where a failure in design results in an obfuscation of valuable customer experience feedback, the essential ingredient to improving the process for both customers and drivers.

What can we do to improve this?

State the question more clearly: instead of sending drivers a function call, ask them a question like “Did everything on this delivery go quickly”? If the answer is “No”, then we can dig deeper and retrieve richer information like:

• Did the restaurant take a long time?
• Was the customer unresponsive?
• Was there a lot of traffic?
• Was there a problem with the food in the order?
• Did the customer provided the wrong address? (Writing 5th Ave W as opposed to 5th Ave E which sends the driver to the wrong part of town. This has happened to me at least twice in one week.)
• Etc.

This is actionable data.

If a restaurant receives many “Slow” ratings from drivers, Uber knows to contact the restaurant to improve their timeliness.

If the customer receives too many “Slow” ratings, Uber can send that customer a message asking them to be more specific with where they are ordering to (including a suite or apt number) or asking them to meet the driver.

The take-away here is, be sure that the customer experience questions are clear to those you are asking. If they are responding to a question they don’t understand, there is no meaning in your data, and you are wasting computational time, storage space, and man hours, or worse, annoy your drivers and customers.

Link to original article: http://www.edankrolewicz.com/product-design/2016/12/12/product-design-misteaks-ubereats