slim UX: Enhancing the checkout experience with talabat Pay
Hello there! This study marks the beginning of a new series called slim UX, where I will examine user experience issues I encounter in real apps and attempt to explore and design potential solutions for them.
My approach begins with observing a situation, and with the help of my analytical skills, I will seek to understand the different ways it may affect the user experience. I will conduct secondary research and competitive audits (where applicable) to gain better insights. Once the problem is identified, I will develop an action plan and design a practical model for a potential solution. Finally, I will sketch the proposed design, explaining why I chose it and how I think it could improve the user experience.
Kindly bear in mind that this series of articles is an individual effort in which I can invest only a limited amount of time and resources. I never claim that the investigations carried out in this series constitute a scientific research model or substitute for in-depth user research and testing. Instead, these efforts only serve as initial remarks that may encourage further analysis.
Background
talabat is a leading food delivery and supermarket app presently operating in the GCC, Iraq, Jordan, and Egypt (where I live). In the Egyptian market, talabat is in direct competition with multiple other apps, including (but not limited to) Breadfast and Rabbit in the supermarket category, and competes with elmenus and Mrsool Egypt in the food delivery category. It also rivals numerous restaurant-owned apps like McDonald’s and Zööba.
Talabat offers a wide range of services and features like talabat Pay, which is a way to collect credits (refunds/compensations/rewards) and use them to pay for future orders. In this brief study, I will tackle an issue I encountered while using talabat Pay and explore probable solutions to improve it.
1. Let me walk you through the situation…
The times I have used talabat Pay so far aren’t many, which has to do with two main factors:
- The only occasions I collected talabat Pay credits were compensations when something went wrong with my order (e.g., a missing item). Thankfully, I seldom faced such problems while ordering through talabat.
- For some reason (perhaps operational or strategic), talabat Pay is available only when paying the total amount of your order online. In other words, if you own 50 pounds in the form of talabat Pay credits and place an order for 100 pounds, you will be required to settle the other 50 using a credit/debit card. I usually prefer to pay in cash; therefore, I feel discouraged from using talabat Pay.
While placing a recent order on talabat, and despite my discouragement, I decided to use my balance and pay the rest with a card. The confusion I felt wasn’t novel; I knew I had been there before! I forgot whether I should add the card first and which payment method to select. “Should I select talabat Pay or the card?” I asked myself. “Wait, I don’t want to use the saved card. Will it allow me to add a different card in another step?” I was uncertain and hesitant.
In the middle of all this, I decided to select the option to add a new card. For a moment, I noticed that the total amount didn’t reflect my talabat Pay balance, but I tapped “Pay” before even realizing it. And just like that, the entire amount was deducted from my card even though I had credits that I could have used! What have I done wrong? Was that even my mistake?
Let’s figure this out!
Hold on, is this a real problem? 🤔
Before leading myself into the trap of false consensus, allow me to pause and check my own biases. I needed to question if other users experienced the same problem, and if so, to what extent.
I would likely need to survey a large enough sample of users to answer such a question. Usability testing can also be an effective method for verifying if users experience difficulties or frustrations during checkout.
Despite my excitement to perform those activities, given the brevity of this revision, I will move forward with the premise that a problem does exist.
2. Identifying the problem
The confusion I felt wasn’t novel; I knew I had been there before!
During checkout, the option to use talabat Pay is displayed equally as one of the payment methods, giving it the same weight as credit/debit cards and cash payments.
Structure:
If, like me, you rarely reserve credits within the app, you may need to multi-select a second payment method to pay any amount that exceeds your in-app balance.
But how would you do that if you are initially required to select either talabat Pay or a card, but not both? Well, if you are using the feature for the first time or rarely using it, there is a chance you won’t know or remember how to accomplish this simple task. In my case, I used trial and error!
Clarity:
When selecting talabat Pay, it tells you how much would be covered by the balance and how much would need to be paid by credit/debit card. But which card? It doesn’t tell. If the user already has one or multiple saved cards, does the app select a card automatically or ask first? On that screen, there is no clue!
Language:
Building on the previous point, a call-to-action (CTA) that says Place Order can be confusing in cases where the user expects an additional step for selecting a credit/debit card to use alongside talabat Pay.
In my experience, I could hardly tell where the button would take me until after tapping it; I didn’t know what to expect. The wording here matters big time. A well-designed experience should not leave users guessing.
3. Competitive audit
With only a handful of relevant apps offering their version of talabat Pay, I chose Breadfast and Zööba as contenders. Both apps feature close-enough models for collecting points/credits and using them to pay within the app.
Breadfast is a supermarket app, while Zööba is a restaurant-owned app; both serve directly to customers using their own systems and delivery fleets.
Breadfast:
Zööba:
The way users can pay with the in-app balance is very similar on both Breadfast and Zööba, with minor differences. Both apps display the feature during checkout as a toggle that users can switch on to use the balance or switch off to save it for later. Unlike talabat, both Breadfast and Zööba allow using the balance simultaneously with any payment method, including Cash on delivery (COD).
The main differences are:
- Breadfast places the toggle after the list of payment methods, while Zööba places it before. A probable advantage to Zööba’s approach is if the balance covers the entire amount of an order, that may eliminate the need to select a payment method altogether.
- Users can redeem Breadfast balance even if it’s less than one pound, while Zööba requires a minimum of 200 pounds to enable it. That, however, seems to be a business decision.
- Other differences relate to how the credits are collected or earned in the first place. For example, Breadfast allows users to add funds to their in-app balance using a credit/debit card, while talabat and Zööba don’t offer this feature. Such differences diverge away from the main focus of this particular study; thus, I won’t go through them.
4. How may talabat improve their experience?
To fully understand the impact of talabat’s current approach on the user experience, in-depth research and testing would be required. However, let’s hypothetically assume that the team at talabat had to decide swiftly based on the findings discussed earlier. What could be the best way to mitigate the existing situation?
Here’s what we know so far:
- Clarity is a critical element to the user experience, and it is more so when users are performing actions that will cost them money.
- Talabat’s checkout screen contains sequences and elements that can cause some confusion and, as a result, may hinder the affected users from achieving their desired goals.
- An alternative implementation already exists in rival apps and, presumably, overcomes the observed flaws in talabat’s model.
Based on the available information, we may hypothesize that increasing the clarity within the checkout page can contribute to an improved user experience.
5. Action plan
Before sketching any changes, let’s summarize what needs to be modified:
- Separating talabat Pay from the list of payment methods would clarify the ability to select both simultaneously. This way, users can confidently set their preferred payment method, whether or not they intend to use the balance.
- An option to activate or deactivate talabat Pay would give agency to the users and make them feel in control of their finances. A toggle switch is a standard component for controlling an action of this type.
- If the user opts to activate the in-app balance, the “Payment summary” must clearly reflect the changes. Users need to know precisely the amount covered by the balance and the remainder to be paid in the selected payment method (if any).
- When the available balance covers the entire amount, the interface should reassure users that their payment methods will not be charged. Visual cues and text can both help clarify this information.
- The wording needs to be revised to ensure the accuracy and clarity of the information provided throughout the checkout screen. Action buttons need to set clear expectations of what happens when tapping them. Whether there is a forthcoming step or the user is about to reach the end of the flow, labels need to be crystal clear, leaving no room for guesses.
- Bonus: talabat may also test a feature (e.g., a text field) that allows users to control how much of the available in-app balance they wish to use for each purchase. This feature would, however, require additional investigation and testing with real users to decide the most effective implementation method. To keep things simple, I will skip this for now.
6. Small decisions that matter
Should the toggle switch be placed before or after selecting the payment method?
While we have seen both implementations in Zööba and Breadfast, the placement of the “in-app balance” section is more intricate in the case of talabat. As mentioned earlier, talabat does not allow the use of the in-app balance alongside cash payments. The reason for this decision remains unclear to me, but I suspect it relates to business operations that go beyond the scope of the UX team.
Nonetheless, I will analyze the following scenarios: if talabat maintains the same policy versus if they change it in the future.
A. Existing scenario: Users can only pay with a credit/debit card while using their balance:
In cases where users can’t select Cash as a payment method, displaying it in its active state may leave them puzzled. Only the payment methods allowed for use alongside talabat Pay should be enabled while hiding or dimming the rest. In this scenario, placing talabat Pay before the list of payment methods could be more logical. If the user activates the toggle, cash payments no longer become available.
B. Probable scenario: Users can select any payment method alongside their balance:
While there is more flexibility in this scenario, placing talabat Pay after the payment methods would give more weight to the latter, indicating a higher priority or being mandatory. Meanwhile, talabat Pay would appear as an optional add-on, which it is!
7. Sketching solutions
With a clear understanding of the requirements, now is the time to visualize how the proposed solution would appear and function in the app.
The focus was to enhance clarity across the entire design and elaborate the connections between the elements. I also worked on allowing users more control over the experience while minimizing the chances of error (Jakob’s 3rd & 5th Usability Heuristics).
Scenario A:
This scenario keeps talabat’s current policy intact, where talabat Pay requires paying the remainder by credit/debit card.
Here, talabat Pay is separated and placed before the payment methods, where activating the feature renders Cash on delivery unselectable. This sequence is deemed more logical since the second component depends on the first.
- A1: When talabat Pay is activated, Cash on delivery becomes unselectable. A tooltip clarifies the reason and the way to change it. “Cash on delivery cannot be selected while talabat Pay is switched on.” This design decision keeps users informed of how they can interact with the interface.
- A2: With talabat Pay toggled off, users can select any payment method, including Cash on delivery.
- A3: Users can’t activate talabat Pay while selecting Cash on delivery. A tooltip clarifies: “To enable using talabat Pay balance, you first need to change the payment method to a credit/debit card.”
- A4: When adding a new credit/debit card, the labels have been updated to set clear expectations of what happens when tapping the action buttons. While there is a small exit button at the top-left corner of the modal overlay, a harder-to-miss, secondary button with the label “Discard changes” enhances user control & freedom (Jakob’s 3rd Usability Heuristic).
- A5: Tapping “Add and review payment” in the previous screen takes the user back to the checkout page to review and confirm all the payment details before placing the order. This additional step is intentional to prevent errors (Jakob’s 5th Usability Heuristic).
Scenario B
This scenario tackles the probability of talabat revoking the previously discussed policy at some point. If that happened, users would be free to pay in any method alongside their talabat Pay balance, similar to the experience on Breadfast and Zööba.
The list of payment methods precedes talabat Pay in this scenario. The aim was to present talabat Pay as an extension to the main feature and to indicate that selecting the payment method is independent of activating talabat Pay.
- B1: Users can freely select any payment method alongside their talabat Pay balance.
- B2: Toggling on/off talabat Pay is reflected in the Payment summary.
- B3: There’s no change in the modal overlay compared to scenario A.
- B4: Similar to scenario A, the newly added card is automatically selected. The Payment summary highlights the split between talabat Pay and the card. The card type and last 4 digits appear below the Total amount due to prevent errors.
- B5: Users can instantly switch to any payment method without affecting the selection of talabat Pay.
Special case:
In cases where the balance can cover the entire amount due, users no longer need to select a payment method alongside talabat Pay. Displaying the list of payment methods here would be unnecessary, if not confusing. I reimagined this specific scenario in a way that could both simplify and clarify the user experience.
With talabat Pay activated, the Total amount due becomes equal to zero, and the list of payment methods morphs into a friendly message that reassures users and celebrates their win: “Your talabat Pay balance has got you covered this time. Yay! 🥳”
A brief description clarifies what to expect and the choices available to the user: “You don’t need to set any payment method for this order. If you wish to save your balance for later, you can switch off talabat Pay.”
There can be many other creative ways to implement the same idea. Following talabat’s unique voice and style, tailored illustrations and animations can enrich the visual experience. Nonetheless, accessibility and clarity should always remain top priorities.
A closer look:
Featured below are close-ups of three main elements that formulated the new design. The changes were focused on enhancing clarity, allowing users more control, and preventing errors.
Talabat Pay has been redesigned and separated from the list of payment methods to improve visibility and user control. New component states were created for better representation of the relationships and areas of overlap between the different elements on screen.
A selected payment method is now easier to distinguish from the rest to prevent unintended selections. When a payment method is unselectable, it is dimmed and accompanied by a tooltip explaining the situation.
The Payment summary is now easier to skim, with an improved arrangement and better visibility of the most crucial bits of information. The CTA adapts to the selected payment method to set clear expectations and prevent unpleasant surprises for the user.
8. Interactive prototypes:
For each of the two scenarios discussed above, I created an interactive prototype in Figma. You can test both yourself by visiting the links below.
Has the problem been solved?
Did the solution work? Has the user experience been improved?
Moment of truth! (Well, not yet.)
To confidently answer the questions above, we first must observe real users testing the new designs. Further research would be required and likely followed by new iterations.
As mentioned earlier, this is the effort of a single person, which in the world of UX design is insufficient for validating the design effectiveness from the perspective of a larger audience.
If what I proposed here was not the right solution, or if I failed to tackle the right problem in the first place, this study can still serve as a starting point for something more solid. I keep an open mind to different points of view and directions, and with your invaluable feedback, I should be able to improve both this design and, hopefully, my future work as well.
Thanks for your valuable time! Peace.
