Case Study Banner
Project Overview
Ria is a money transfer app, that allows users to transfer funds internationally. The goal was to improve the error resolution to reduce drop-off rate.
Industry project
Data-driven design
UX design
Skip to prototype

Project details

Organization : Ria Money Transfer | Euronet

Role: I was the sole product designer working cross functionally with the product owner, product analyst and engineers.

Timeline: 2 Weeks, shipped October 2023

Tools: Figma, Figjam, Amplitude and Logrocket.

Technology now has the single largest impact on an organization’s ability to react, innovate and succeed. Today’s industry leaders have embraced this and literally changed. Of course, everyone uses technology to change in different ways, but we believe customers can take.

Rapid growth in digital and mobile technology is changing the advertising industry, and the UK is leading the charge, with digital set to claim more than half of all advertising spend in 2016, according to a recent report from marketing.

Problem overview

Through analysis of the user drop-off in the money transfer journey, we found that:

Users struggle to understand errors related to money transfer limits.
Users would create multiple transactions for sending higher amounts.
Users don’t know how to increase their transfer limit to send higher amounts.

Roadmap to data informed design process

Leveraged insights from analytics during research and design phase to drive design decisions.

Research Image
Step 1: Analyze

Analyze product metrics to identify potential problem areas.

Go to section
Research Image
Step 2: Understand

Leveraging observations of live user sessions and user interviews.

Go to section
Research Image
Step 3: Align

Scoping and alignment with stakeholders on project goals.

Go to section
Research Image
Step 4: Action

Design a solution that helps users resolve errors easily to reduce drop-off.

Go to section
Step 1:  Analyze product metrics

Analyzing the transaction creation funnel I observed a huge drop-off after users had confirmed the quote but before the transaction was created.

Analysed user drop-off at various stages in the money transfer funnel using Amplitude.
Omniversity platform
This graph represents the user drop-off at various stages in the money transfer funnel.
Useflow Map Image
Fidelity Image

Next step was understanding if the drop-off was at the customer end or an issue within the app.

Analyzing the payments funnel
Digging deeper into the product metrics of active users to pin-point the data points where the users dropped off.
Omniversity platform
Customer drop-off in the payments funnel
📉 Observation
A 32.7% drop-off between the stages of creating a transaction and it being processed within the app.
💡 Hypothesis
Indicating that the issue was within the app as users were happy with the transfer rates and wanted to commit to the transaction but failed after confirming to proceed.
Step 2: Understand

Understanding the issue through the user

Leveraging observations of live user
sessions
of customers using the app at the drop-off point.

Insights: Since the users had no verification issue and the problem was with limits on transfer amount.
Exploring three use cases that could cause this issue:

  • Payment or delivery method limits
  • Country based limits
  • Tier based limits on individual.

Tool used: LogRocket

Unearthing user pain points from in-depth interviews

Conducted interviews with 7 users facing transaction issues due to payment limits.
Use flow Image

Key insights

The error message is vague and does not inform the user if the transfer limit is on the payment or delivery method.

The user does not know the various kinds of limits on transaction i.e payment & delivery method , country based and tier based limits.

User does not know they can change the payment or delivery method to send higher amount.

Highlighting this was clearly a usability issue combined with lack of information making the user frustrated and resulting in the drop-off.

Concept trade-off discussion with product and engineering folks

Step 1: We realized that the scope of this issue was large and had to be simplified.
  • Calculator-based limits: Which involved informing the user about transfer limit based on the payment and delivery method.
  • Country-based limits: Analyze different types of limits based on the country and individual tier-based limit.
Step 2: Analyze constraints and time-lines:
  • Calculator-based limits: Easy and faster to implement with maximum impact. Had existing information on the various limits and could use existing backend infrastructure to implement this.
  • Country-based limits: Gathering compliance information for all countries poses a significant time and effort challenge, alongside the need for substantial investment in technical infrastructure.
Final decision:
To start with calculator-based limits as it was quicker to execute with limited engineering bandwidth and had maximum impact.
Story Image
Story Image
Competitor analysis

Came across a diverse set of approaches that enabled users to update the payment or delivery method when facing issues in completing the transaction.

Remitly

What works for Remitly is clear messaging and easy error resolution, as users can increase their transaction limits, change the payment or delivery or send a lower amount.

Story Image

Wise

What works for Wise: Good error prevention; based on the transfer amount, users can only select available payment or delivery methods.

Story Image
Fidelity Image
Step 3: Scoping and alignment

Analyzing the constraints and time-lines, we discovered:

  • Limit based on the payment and delivery method: Easy and faster to implement with maximum impact. Had existing information on the various limits and could use existing backend infrastructure to implement this.
  • Country-based limits: Gathering compliance information for all countries poses a significant time and effort challenge, alongside the need for substantial investment in technical infrastructure.
Working with the product team, we realized that the scope was large and had to be simplified. Based on maximum impact, we prioritized error resolution based on payment and delivery method limits .
Step 4: Action

What would work: Do we only make the payment/delivery methods available depending on the transfer limits or allow the users to change the method that would allow them to send higher amounts?

Leveraged analytics to understand user preferences and identified primary trends that shape user behavior.
Design Image
Design Image
Design Image
Findings about user preferences  

Allow users to change the amount or the payment/delivery method as users had mixed preferences, some users prefer to stick to the same payment methods while others change frequently.

❎ Inconsistent for some payment methods

61% of users using “pay in person” as their payment method change their payment method.

✅ Consistent for user using bank transfers and debit cards

Only 5.87% users using debit cards and 11.6% of users using bank transfers changed their payment method.

Building on insights from user interviews, CTR reports, competitive research, and heuristic evaluation,
I established the following design goals.

Establishing design outcomes
User Research
#1 User control and freedom

By introducing two intuitive buttons, we empowered users to easily rectify limit issues by adjusting the transaction amount or changing the payment/delivery method.

#2 Clear messaging

Clear error messages were introduced to inform the user of where the limit is and guide users on how they can resolve the issue.

Components created

Created new modals and list items for the design system

Modals

Featuring concise error messages and intuitive buttons for effortless resolution of limit issues through adjustment of transaction amount or modification of payment/delivery method.

Story Image

List and list items

Showing only the available option based on the amount entered which is good practice for error prevention.

Story Image

High fidelity prototypes

Resolving payment method error

  • Clear error messages show maximum transfer limit for chosen payment method.
  • Resolve issues easily with buttons to adjust amount or change payment method.
  • Opting to change method reveals a list of available payment methods based on transaction amount, while selecting amount redirects to the calculator.

Resolving delivery method error

  • Simple error messages displaying the maximum transfer limit for the chosen delivery method.
  • Easy error resolution by adjusting the transaction amount or changing the delivery method.
  • Opting to change method reveals a list of available delivery methods based on transaction amount, while selecting amount redirects to the calculator.

Aligning the final prototypes with design outcomes:

Clear and concise messaging ensures that users easily understand the issue.  
Simple error resolution to make the app more user-friendly.
Impact

Removing vague error messages and allowing simple error resolution to the new designs have increased engagement and retention rates for the customer experience.

Decreased number of calls to the customer service team.
Increase in the number of transactions by active users.
Higher value transactions by the customers.
Reduced customer drop-off by 80 % at the quote confirmation stage.

Implementation and next steps

Currently only the messaging has been implemented and next steps are to introduce the buttons for error resolution.

Future goals; Work on the error resolution for

1. Country based limits 🌎
2. Tier based limits 🪪
This is will require digging deeper into compliance requirements based on the senders and receiver's country as well as verification level.

Checkout my other projects

Streamlining UX Learning and content creation

UX Research

UX Design

Designed a community-driven platform making UX resources easy to find, use and understand.

Read Case Study