| Table of Contents |
|---|
⏮️ Context
| Info |
|---|
What is the context and status quo of the opportunity |
https://rbictg.atlassian.net/servicedesk/customer/portal/53/IREQ-2297?created=true
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).
...
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 (details here), 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
| Info |
|---|
Summary of the opportunity's’s main findings and what is going to be addressed |
One of the errors that we have identified that occurs in the Payment is related to the pre-filled “Name on Card” field.
Analyzing the errors details from the paycomet database since BK PT migration, we could measure that the name on the card (Error 115 - “The card issuer could not identify the owner”) leads to 3.8% of error sessions (monthly average). On average, 29.6% of payment sessions has some error. Thus, this error represents 13% of the payment errors (3.8% out of 29.6%). There are only two errors that are higher: 102 - Operation not allowed for the card type: 9.8%; and 1099 - Unexpected error: 3.9 %.
When the user selects the option to add a new credit or debit card, the “Name on Card” field is found prefilled by default. The name that appears is the one the user had entered when signing up.
However, this name may not match with the name on the Card and the user may not notice the mistake, so when they finish filling in the form, the error message is displayed to inform the user about the mismatch.
...
❔ Expected Outcome
| Info |
|---|
What are the goals the opportunity is going to address |
Our goal is to avoid the user making preventable errors. We think that if we let the user introduce their “Name on Card” by themselves, less mistakes may occur regarding the Card details.
DoD
In Whitelabel-app:
The pre-filled info in the “Name on Card” field has been removed.
The “Name on Card” field appears empty, only showing the place holder (which is the “Default” State in the Design System)
The required fields are marked with “*”.
Show the Label in “Focus” “Filled” and “Error” field states, so the user has an extra guidance of what they are filling up.
Focus State:
Filled State:
Error state:
📈 Success Metrics
| Info |
|---|
List here which are the metrics to look at to define success for the solution implemented. Use those KPIs to define the current status |
Reduce payment errors
Increase purchase conversion from payment to purchase
❓ Open questions
| Info |
|---|
We need to make this section empty constantly. |
Is there any reason behind to ask for the Name on Card in the current flow in all markets?
Does the current “add new card” form allow the user to fill the fields using browser autofill? If it does not, should we add this to our DoD? (this only affects the web).
I’m guessing this task doesn’t require a Sanity, DOP, .etc configuration, but we should confirm this.
Insights
1️⃣ Stakeholder Interviews
[Document here the main insights from interview if applicable]
2️⃣ Analytics
[Document here the main insights from analytics if applicable]
3️⃣ User Research
[Document here the main insights from research if applicable]
4️⃣ Competitor Landscape
...
In Figma (link: https://www.figma.com/design/wEeYkRHLwLdMJHKvQJOdd0/%5BIBFEC-1795%5D-Remove-Pre-filled-Name-On-Card-field?node-id=7979-30251 ) we have mapped 9 competitors + 2 other apps to analyze how the “add a new card” form flow works.
We looked for answering these questions:
Do they ask for the name on the card?
Do competitors have pre-filled fields, especially in the “Name on Card” field?
How do they call the label for the name on the card field?
Where is the name on card field positioned (after or before Card Number field, etc.)?
After this analysis, we discovered that:
In 9 of 11 the name on the card is asked.
All competitors don’t have pre-filled fields, including the name on the card field. The user must enter all the data manually or by Copy/Paste.
In 1 of 9 the name on the card is split in 2 different fields (Name and Last Name).
The position of the field varies between competitors: most ask for the name on the card last (4 of 9); others ask it in first place (2 of 9) or in second place, after the card number field (2 of 9)
5️⃣ Desk research
We did Desk Research to find out if the way we order the fields could affect the conversion rate (CR).
There was not relevant information about this, despite of some opinion articles like this one How to build a killer credit card checkout page that converts, which claims that it does not really matter:
We also did some Desk Research to collect the best practices regarding text fields:
NN Group: Marking Required Fields in Forms. In this article, NN Group recommend the use of asterisks, or the word “Required” to bold the mandatory fields to visually facilitate the identification of the required from the non-required fields to the user.
NN Group: A Checklist for Designing Mobile Input Fields. In this article, NN group list 14 guidelines to follow for input field UX that we reviewed to ensure the current flow meets them:
Zuko: Does using browser autofill affect form conversion rate?.Zuko conducted a studio to know if the autofill could affect the CR. The insights have revealed that it does in a positive way: autofill is positively related to users successfully completing forms.
Also, we did more Desk Research to understand why there are some competitors in our benchmark that don’t ask for the Name on Card. It seems that this topic is an open discussion (see UX.Stackexchange thread). Some UX claim that users can feel more secure while other sites claim it does add an actual extra layer of security (Merchant Authority, Greenlight) so our initial recommendation is to not remove this field.