[Opportunity] Block user from closing window
- Pereira, Filipa
Context
What is the context and status quo of the opportunity
https://rbictg.atlassian.net/servicedesk/customer/portal/53/IREQ-2301
It has been found that between the Payment and the Purchase steps in the funnel, Popeyes ES has scope for improvement in comparison with other markets (e.g.: Germany).
Figma files with more details:
Popeyes ES abandonment rate is about the 11.8%
After analyzing the current flow (between the Payment and Purchase steps) and sync the findings in the Checkout discovered by the Fulfillment Team, our initial hypothesis of which could cause this rate were:
· Users may find unexpected and unclear errors when they are in the payment process.
· Users may feel that the actual payment process is slow.
· Users may feel that the actual payment process is complex.
Problem Statement
Summary on the opportunity main findings and what is going to be addressed
One of the errors that we have identified that could happen on the Payments page is when the payment is being processed:
When the user places the order (presses the button), the button state changes to a loading state, blocking the user to press it again. However, the rest of the page do not change or blocked, having the possibility to return to the previous step in the middle of the process (press X to close).
Permitting the user to go back during the payment process is a risk, because the payment process is an important step in which Payment and RBI platforms are involved. Their interruption leads to several errors, depending on when the user closes the page. Once the user comes back to the Checkout, these errors may occur:
If the user presses the Continue button to place the same order again, the page informs the user that they have already placed the order (duplication) when it has not.
Important: Every time the user continues the purchase from the Checkout to the Payment page, a unique Transaction ID is created to track the order. So, if the user cancels the payment (eg.: selects Bizum but presses the “cancel” button), they return to the Checkout Page to create a new Transaction ID.
Expected Outcome
What are the goals the opportunity is going to address
Our goal is to avoid errors that may lead to high levels of frustration and a high volume of Customer Support incidences.
We think that blocking the user from closing the page while the transaction is being processed will reduce the volume of errors that might occur.
Success Metrics
Importance | What do we want to measure? | Description | How are we measuring it? |
|---|---|---|---|
Primary metric | Number of errors produced while processing payment | We would like to decrease this number. We expect to see a higher number of conversions. | Amplitude |
Primary Metric | Number of incidences in Customer Support related to Payments issues | We would like to decrease this number. | ?? |
Open questions
About Card User cases:
Card Data Verification:
When the user adds a new card, how does the Card Data Verification work? I mean, the happy path shows the users that they get both card and purchase confirmation done pressing the “Place Secure Order Button”, but I guess we’re doing two processes in the back. What’s going on behind? Does this process take long?
Can the Card Data Verification be interrupted (Go back) with no risks of generating future errors in the purchase?
If a user tries to pay with a previously saved card but now it is not valid (has expired, is blocked by the bank, etc.), do we show a modal informing about the problem. After that, does the user must return to the Checkout to create a new Transaction ID or can they stay on the Order Payment Page (conserves the same Transaction ID)?
If a card payment was not successfully processed, does the user have to return to the Checkout to create a new Transaction ID instead of staying in the Order Payment to select another Payment method?
Paycomet Payment Verification Modal:
How does the Payment Verification modal layout work? Where does the user find the code they must enter to proceed?
Is any chance to adjust the Payment Verification modal layout?
About Online/Mobile Payments Apps:
In the PayPal, Waylet, Apple and Bizum user cases in which an i-Frame (App) or a new window is opened (Desktop), if the user closes or cancels, where do they go? Do they must go to the Checkout page or can they stay on the Order Payment page?
If a PayPal, Waylet, Apple or Bizum payment was not successfully processed, does the user have to return to the Checkout to create a new Transaction ID instead of staying in the Order Payment to select another Payment method?
Is there any other platform to consider besides the Whitelabel-apps for this task?
Insights
Stakeholder Interviews
[Document here the main insights from interview if applicable]
Analytics
[Document here the main insights from analytics if applicable]
User Research
[Document here the main insights from research if applicable]
Competitor Landscape
We look into the competitors to find how they resolve the same problem and which solution they have implemented.
We identified 2 common patterns to block the user from going back during the payment process:
Pattern 1: the loading state of the payment processing is displayed in a different page (loading page)
Pattern 2: the loading state of the payment processing is displayed on the same page but blocking the whole screen (disabled state). We found two ways:
Loading icon and a black transparency mask covering all screen to indicate the user the screen is blocked (disabled) and they are not able to do any action:
Loading icon and disabled state in all actionable elements: checkbox, buttons, etc., including the “Go Back” action:
Market analysis
We mapped the current behavior of the Close/Go Back action regarding the different payment methods in all markets. This previous analysis is important to ensure that the final solution covers all the markets needs and its singularities.
These are the markets current behavior (check it better on Figma):