2024/6 - 2025/1
End-to-end design process, User testing
With around 80% of users adding money to PayPay E-money through ATMs, we’re expanding ATM functionality this year to offer cardless deposits and withdrawals at our our bank service.
Our goal is to enhance ATM services and deepen user engagement. Since many people in Japan still use cash, we see this as an opportunity to bring them closer to PayPay and gradually guide them toward cashless payments.
↗ 12% increase in services adaption rate
↘ 13% decrease in customer service inquiries
Product Demo
Users can now access all ATM features using just their smartphone—no need to carry a bank card.
Also in testing, the average transaction was completed in 30 seconds, faster than the typical 45-second card-based withdrawal.
Understanding the business goal
This project focuses on expanding ATM-related features and increasing their visibility. Since many people in Japan still use cash, we see this as a way to bring them closer to PayPay and gradually help them shift toward contactless payments.
We already support e-money top-ups and are now adding features like cash-out and cardless deposit/withdrawal from PayPay Bank (following our recent merger). A key challenge in this project is integrating these new features seamlessly into the existing experience.
E-money cash-out
Bank cardless deposit/withdrawal
But with tight timelines and limited resources
We needed to carefully prioritize which features to build first. I joined a brainstorming workshop with the PM and business teams, where we used an Impact vs. Difficulty matrix to evaluate our options.
My focus was on identifying which feature would deliver the most value to users. After discussions, we decided to move forward with cardless deposit/withdrawal.
It addressed a clear need, was easier to implement, and aligned with our 2025 goal of integrating services into one platform. In comparison, e-money cash-out had potential but involved more regulatory complexity and development risk.
Defining the Problem
Identify the user flow
I visited an ATM and tested the process using competitor apps and benchmark common design and flows.
Gather insights from customer support team
I collaborated with the customer support team to gather user inquires regarding cardless ATM. We then grouped them into key categories for further synthesization.
Review the flow and data
I worked with data anaylst to look at the flow and data to find where most users were dropping off or having issues.
Mapping the User Journey
Traditional flow vs. Cardless flow
Simply put, there are 2 main differences between the flows—and also the key reasons behind most transaction failures:
Extra setup required: With the cardless flow, users need to go through an initial setup, including KYC at the first time, to prevent fraud.
Switching between devices: In the traditional flow, everything happens on the ATM. But with the cardless flow, users have to switch between their phone and the ATM.
Pain Point ①
Around 40% of users fail during the initial setup
We need to verify users to prevent fraud by initial set up, but the available methods each work slightly differently—making it unclear what users should do or which option to choose, often resulting in delays.
Pain Point ②
About 13% of users drop off after scanning QR codes due to unclear instructions
After scanning the QR code on the ATM, users see a corporate number on their phone that they’re supposed to enter on the ATM. But since there aren’t clear instructions telling them to switch back to the ATM, many get confused and don’t know what to do next.
Pain Point ③
No clear confirmation after withdrawal/deposit—7% of CS inquiries relate to this step
Because of technical limits, we can’t show the withdrawal or deposit amount—and the total balance—during the cardless flow. This makes users unsure if their transaction actually went through.
Besides user pain points, I also laid out some high-level design goals to help keep the direction clear.
Keep the experience as simple as using a regular cash card
Integrate new features without interrupting the existing experience
Work within technical limitations
Ideation
I created wireframes and flows mapping between mobile and ATM screens.
After reviewing the early concept with team, I received a variety of feedback, especially about the entry screen for services selection, which is one of the most improtant screens of the flow
User testing
I created 3 concepts based on the feedback and tested them with 8 participants.
Asking about their first impressions, what caught their attention, and where they would interact to complete the task.
Concept 1
Adding icons to make the buttons stand out more and better highlight the differences between options
Concept 2
Tring vertical button layout to improve scanability
Concept 3
Adding illustration to draw attention to the call to action
Some quick insights:
"Adding icons helped users recognize the options more easily."
"The illustration didn’t add much value and just made the screen feel cluttered."
"Users preferred the horizontal button layout, as it better matched the overall page structure."
After user testing, we moved forward with Concept 1 since the results were more positive.
Concept 1
Adding icons to make the buttons stand out more and better highlight the differences between options
Final design
With a bit of tweaking and refinement, I finalized the design.
*Only critical screens are shown here.
Choose withdraw/deposit
Scan QR code
Display Bank number
Complete transaction
Then we found a critical issue — where users start the flow
In my final design, users were expected to select a service in the app first, then match it on the ATM and scan the QR code.
However, some users start at the ATM, then use the app’s general scan feature—originally for Scan & Pay. This works for now with only one ATM service (E-money Top-Up), but after launch, we’ll support multiple services, and the app won’t know which was selected on the ATM.
This leads to confusion, repeated steps, and potential mismatches—like choosing withdrawal on the ATM but top-up in the app—causing failed transactions.
To solve this alternative route issue, I worked closely with developers to explore solutions. We decided to add a condition check—if a user hasn’t linked a PayPay Bank account, we assume they’re using E-money Top-Up and take them directly to that flow after scanning.
I'll skip the technical deep dive, but we held multiple sessions to define which API status checks to use. Below is the final flow we implemented.
With this condition check, users no longer need to reselect a service. Scanning alone becomes the entry point, and the app routes them based on their intent.
Along with the condition check, I also added a tutorial on the screen to introduce the new screen and reduce confusion.
Adding tutorial ballon
Before
After
Results
12%
13%
Some reviews from users
Super convenient! I love how I can withdraw and deposit cash without needing my card.
The process is smooth, and the instructions are clear!
Really useful feature! The interface is intuitive, and I can set up easily!
Future Ideas
During the iteration, I also came up with some ideas for future improvements, such as:
Play a haptic pattern to reinforce that the number input was successful.
Before
After
Instead of ending on a static page, the app now retrieves data from the ATM via API after the transaction is completed—displaying the success status and amount to improve the overall experience.
Learning
Throughout this project, I gained several some insights:
When faced with unclear or ambiguous requirements, it's crucial to raise questions early. Doing so not only saves time and resources but also ensures the team is aligned with the company’s goals from the start.
Bringing features together across multiple devices and services takes careful effort. User testing and observing in real-world scenarios are crucial for spotting issues that might not appear in theory or isolated development.
No matter how thorough the initial research is, user behavior in real-world scenarios often diverges from expectations. Continuous follow-up and iterative improvements based on actual usage data are essential to refine the product and truly meet user needs.
