Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
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). 

...

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

...

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.  

(blue star) 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. 

...

  • 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). 

...

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.  

⏭️ Design

Figma Link: https://www.figma.com/design/wEeYkRHLwLdMJHKvQJOdd0/%5BIBFEC-1795%5D-Remove-Pre-filled-Name-On-Card- field?node-id=7979-30251 ) Important: there are 2 different Payment Pages designs for each type of order: Delivery and Pick-up orders. By now, this should not affect the Dev Team but the Core FE.  Also important: the pick-up orders flow has 2 variations depending on when the confirmation store was configurated to be displayed in the front: Store Confirmation page is activated before or after Order Payment page.