Being transparent in the face of uncertainty.
Don't have time to read everything? Skim colored text to get the gist.
Favor is an on-demand delivery service that allows people to get almost anything delivered in under an hour. In addition to being able to browse menus in the app, users can simply type in a place and what they want, and a Runner will go get it for them. The ability to order anything through freeform text means that the final cost is not always known until a Runner pays for the items. Customers may also request changes or additional items after placing the order, further complicating efforts to show an accurate total at checkout.
The design in production at the time purposefully hides the order total behind a link, due to business concerns that customers would order less, or not at all after seeing the final amount. However, one of the worst and most common complaints about Favor is exactly that—not seeing the total before ordering. Even those who find the link are likely disappointed to see a breakdown of price with no itemized list.
Though Favor heavily advertises food delivery, you can order almost anything.
Our goals in rethinking the checkout flow are to:
Show more accurate pricing for an order when part of it is unknown.
Breakdown price in a way that makes sense for users.
Address other major issues that emerge during research, such as confusion surrounding terms like “processing fee” and “estimated order total.”
Make it easier to review orders by removing the calculate button and cleanly displaying all of the information on one page.
Tapping "calculate" (left) opens a separate page (right) that shows the order total.
First, Itemize pricing at checkout so known costs can be separated from those we don’t know.
Then, break down price the way customers expect to see it, specifically separating out cost per item, tax, delivery fee, and tip. Retain the second fee without creating another line item by rolling it into the cost of goods.
Next, take the "processing" out of processing fee. A short explanation is easier to understand, and circumvents preconceived notions associated with other terms.
Finally, explain upfront why the prices are estimated, by describing the ways in which the total may change after checkout.
All of these changes make price much more transparent, clear up several points of confusion, and make the experience more fluid.
HOW WE GOT THERE
Focus groups led by Favor’s parent company, H-E-B, revealed some negative perceptions about the service. For example, many people believe Favor is more expensive than its competitors, even though the cost is actually the same or even less in some cases. These early findings prompted the team to better understand Favor's pricing model and how customers judge the value of services like Favor.
We begin by internally reviewing the design in production at the time, which has some immediately noticeable problems.
Rather than display the total by default, users have to tap “calculate,", which navigates to a separate screen.
If there are more than a few items in the cart, estimated order total falls below the fold, and out of sight.
If the price of even one item is unknown, everything that depends on the item subtotal displays as TBD.
The main page for reviewing your order shows no pricing information.
If the order contains a custom item, almost everything is TBD.
To better understand our users’ experiences, we set up tasks on usertesting.com and ask for general feedback. We explored and tested different variables through dozens of iterations and with more than 350 unique participants in all. The demographic is limited to Favor’s potential user base, only including people in Texas who have ever used a food delivery service. Each round of research consists of multiple test variants, presenting screens in different sequences to mitigate question-order bias.
Our main research focus is determining the best way to present order details for customers, while also addressing other feedback along the way.
presentation of price
The original breakdown of an average order consists of only 5 line items:
Estimated Item Cost (includes tax)
Estimated Processing Fee
Estimated Order Total
Early on in our research, we found issues with nearly everything listed above, and discovered something that customers expect to see, but is missing here.
So let’s get into it, starting at the top...
Original breakdown of price. When 1 item's price is unknown, almost everything is TBD.
The original price structure only included total item cost + tax, processing fee, and delivery fee.
Itemization & Tax
Consolidating all the items and tax into one number proved to be problematic. First, if the order contains even one custom item (where the price is unknown), then the entire value becomes unknown. The second problem, which became clear through testing, is the absence of tax as a separate line item. Users are unsure if tax is already included or if it is added later, which would result in a higher total than shown at checkout.
Each item is listed separately and known prices are added to the overall item cost.
Indenting sub-items, and reducing their prices' visual weight, makes them easier to distinguish. The option to hide sub-items helps reduce clutter.
Custom items can significantly change the final cost, so we are showing all uncertain prices as TBD.
Another piece of feedback we receive consistently is a negative reaction to multiple fees. People feel like they are being nickeled and dimed when they see yet another fee on top of the delivery fee and tip, plus the original order amount. Thus, we need to find a way to retain the revenue from the processing fee without vexing customers.
V1 - Combined with Tax
People want to see tax separately, and feel that combining it with a fee is deceptive.
V2 - Added to Delivery Fee
Putting the processing fee with the delivery fee inflates this number too much.
V3 - Combined with Item Cost
Users are more receptive to increased item cost than fees, and prefer this structure.
H-E-B's prior research unequivocally shows that people do not understand or like the term “processing fee,” as many of them question what it is for. So the task is to identify a term that elicits a neutral, or even positive, reaction to the fee.
We put together a list of names, including those that our competitors use, and tested them. Below is a summary of the feedback we got for each one.
Similar to prior research, people react very negatively to Processing Fee.
Service Fee is slightly better; however, since the service is delivery, people wonder what the difference is between this and the delivery fee.
Convenience Fee makes people feel like they are arbitrarily being charged more.
Booking Fee is a surprisingly good choice. People understand what it means, and accept it with little resentment, but it is associated with Uber Eats.
The last option takes the name out completely, and combines it with a simple explanation: “Each order includes a 9% fee to help us operate Favor.” Though the explanation is vague, most users are satisfied due to its transparency.
We chose to go with a nameless fee, in order to avoid the negative connotations and ambiguity found in other terms. Due to business concerns, we are not showing the exact amount for the 9% fee; however, since people find percentages difficult to calculate, we are adding an example that helps quantify the percentage in terms of dollars and cents.
Each order includes a 9% fee to help us operate Favor (Ex: $0.81 for a $9 item).
"Estimated" Order Total
One of the things that repeatedly came up during research is concern over the word “estimated,” as it implies that the total may change after checkout. Though there is explainer text at the bottom, testing shows that few people actually read it. The uncertainty implied by "estimated" makes many users feel uncomfortable, dissuading some from even placing their orders.
Due to the imprecision of Favor’s current ordering system, it is common for the total to change, because of things like substitutions and add-ons. Therefore, “estimated” cannot simply be removed, and must remain part of anything that relates to item cost. That said, we must figure out another way to address customers’ concerns.
We explored and tested 2 variables: 1) the wording of text explaining why the total may change, and 2) the text’s placement in the app. Each iteration was incorporated into other, unrelated tests, allowing us to be more time efficient while getting feedback on the experience as a whole.
V1 - Simplified Text
Short text lowers the barrier to reading, but its position still does not draw attention.
V2 - Better Information Architecture
We refined the text and positioned it for better IA and visibility.
Reorganizing the text and making it more succinct and clear completely alleviates users' concerns.
Many users find it confusing and frustrating that tip is not included in the total, nor adjustable at checkout. However, changing either of these could impact the business, and must be independently researched and tested. Because this would add significant scope, the goal at this time is only to clarify that tip is adjustable after delivery, with further changes to be explored later.
Since this issue is similar to explaining the term "estimated," we tested the same solution, placing text below Suggested Tip. We found that this simple explanation greatly alleviates users' concerns, while keeping the design consistent. Although this is not a permanent solution, it buys us time until we are able to investigate the full impact of adding tip to the order total.
You can adjust tip after delivery.
Putting it all together
Every item is stipulated, with known costs displayed.
Tax is its own line item, as customers expect.
Processing fee is part of item cost, which customers prefer.
The percent fee is phrased in a more understandable way.
Explanations are given for estimated order total and tip.
Click the gif above to see the prototype.
Although online usability testing is great for getting quick feedback from a relatively large group of people, it is difficult to account for real life factors like hunger. It is important to back up these findings with live data to ensure the conversion rates and revenue will not drop as a result of full scale implementation.
Therefore, the product and engineering teams launched a series of A/B tests in production to assess our findings; however, at the time of writing this, the tests are still ongoing, with statistically significant results yet to be seen.
While this project yielded many invaluable insights, answering some questions almost always leads to more. The product team plans to continue evolving the app with further exploration into:
Prices for delivery fee, including psychological pricing (e.g. $2.99 vs $3).
How conversion rates are affected when including tip in the total.
A complex data structure for menus that fully supports modifiers, enabling us to estimate cost much more accurately.