Cardless ATM
Overview
Japan still runs on cash nowaday. Despite the rise of mobile payments, ATMs process millions of daily transactions, and most people still carry a bank card just to use one. At PayPay, I saw an opportunity to change that.
As the lead designer on a cross-functional team, working alongside PMs, engineers, and business partners, I redesigned the ATM experience from the ground up, expanding it to support cardless deposits and withdrawals through PayPay Bank. No card. Just your phone.
The hard part wasn't the idea, it was the execution. I had to unify a fragmented experience across two very different devices: a smartphone app and a physical ATM, each with its own constraints, regulatory rules, and screen specs. The goal was to make the whole thing feel as simple as using a regular cash card. After launch: 12% increase in service adoption, 16% rise in transaction success, and 13% fewer support inquiries.
PayPay
Company
Fintech
Industry
2024/6 - 2025/1
Timeline
End-to-end design
User testing
Responsibility
0
0
%↑
Services adaption rate
0
0
%↑
Trasaction success rate
0
0
%↓
Customer service inquiries
Product Demo
With this feature, 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.
PayPay's North Star was clear: convert cash-dependent users into active PayPay users, not by forcing them to go cashless overnight, but by meeting them at the ATM, which is where they already are.
The context matters here. Over 50% of payments in Japan are still made with cash, and even as the cashless payment ratio reached 42.8% in 2024, cash remains deeply embedded in daily life. Our target wasn't new users, it was the segment already on PayPay but still defaulting to cash: people who had the app but hadn't fully committed to the shift. If we could make topping up their e-wallet as frictionless as visiting an ATM, we had a real path to re-engaging them.
Challenge: Tight timelines and limited resources
Not every ATM feature was worth building first. To align the team on priorities, I joined a workshop with the PM and business partners to map potential features on an Impact vs. Difficulty matrix.
My role wasn't just to execute — it was to pressure-test assumptions. During the session, I flagged that one of the higher-priority candidates had significantly less user value than the team expected. From what I'd seen in user behavior and existing pain points, the feature solved an edge case, not a core need. That shift in framing changed how we scored it, and cardless deposits and withdrawals moved to the top, the highest user impact with a clear path to implementation.
Before jumping into solutions, I needed to understand the experience from the ground up, not just from data, but firsthand.
I started by visiting an ATM in person to test the cardless flow myself, alongside competitor apps that offered similar features. The goal wasn't to copy what others were doing, most competitors had already solved the basic flow in similar ways. What I was really looking for was where the experience broke down: the moments of hesitation, the instructions that didn't quite land, the points where switching between phone and ATM felt disorienting. Experiencing it myself made those friction points visceral in a way that data alone couldn't.
To triangulate, I worked with the customer support team to audit existing user inquiries around the ATM experience, grouping them into key failure categories.
Then I partnered with a data analyst to map drop-off points across the actual flow. Together, these three inputs gave me a clear picture: the problems weren't random — they clustered around a few predictable moments, which shaped exactly where I focused the design work.
Mapping User Journey compared with traditional card-based flow
The research pointed to three distinct moments where the experience broke down.
Three different moments, but the same underlying pattern: users lost confidence because the experience didn't give them enough information at the right time.
Pain Point ①
Users couldn't get started.
The initial setup, required for fraud prevention, offered multiple verification methods that each behaved slightly differently, with no clear guidance on which to choose. 40% of users failed at this step before ever reaching the ATM.
Pain Point ②
Users got lost between two screens.
After scanning the QR code on the ATM, the app displayed a number to enter back on the ATM, but never told users to switch back. Without that prompt, 13% dropped off right there, phone in hand, waiting for something that wasn't coming.
Pain Point ③
Users left not knowing if it worked.
Due to technical constraints, the cardless flow couldn't display the transaction amount or updated balance at completion. That uncertainty drove 7% of all CS inquiries — users essentially asking: "Did my money actually move?"
Ideation
With the pain points mapped, I set 3 design principles to anchor every decision that followed.
As simple as a cash card. The cardless flow introduces inherent complexity — setup steps, device switching, new mental models. My job was to absorb that complexity in the design, so users never had to feel it.
Additive, not disruptive. Millions of users already used the existing ATM experience. New features had to fit in naturally — without forcing relearning or getting in the way of users who weren't opting in.
Honest about constraints. Technical and regulatory limits were real and non-negotiable. Rather than fight them, I treated them as design parameters, things to design around thoughtfully, not pretend didn't exist.
I translated these principles into wireframes, mapping the interaction across both the app and the ATM screen in parallel. When I presented to the team, most of the flow held up, but the entry screen, where users choose between services, surfaced the most debate. It was the first real decision point in the flow, and how we handled it would set the tone for everything after. That became the focus for the next round.
User testing
Based on the team's feedback on the wireframes, I identified three distinct directions to explore for the entry screen, each testing a different hypothesis about how to help users quickly understand their options.
Concept 1
Added icons to each button, making the options more visually distinct at a glance
Concept 2
Switched to a horizontal layout, betting that a linear arrangement would be easier to scan
Concept 3
Introduced an illustration to reinforce the call to action and give the screen more visual weight
I tested all three with 8 participants via Zoom using Figma prototypes, asking about first impressions, where their attention landed, and whether they could complete the task without guidance.
The results were clear: icons helped users distinguish options faster, the illustration added visual noise without adding clarity, and users gravitated toward the vertical layout, which aligned better with the rest of the app's structure.
I moved forward with Concept 1. Beyond the test results, it was the right call for a deeper reason: icons gave users a visual shortcut without requiring them to read every word, which matters when someone is standing at an ATM, under mild time pressure, with a queue behind them. Concept 2's vertical layout, while scannable, broke consistency with the existing design system. Concept 3 solved a problem that wasn't really there, users didn't need more motivation at this step, they needed more clarity.
With the concept validated, I moved into final design, refining the flow, cleaning up the copy, and pressure-testing each screen against our constraints.
*Only critical screens are shown here.
Choose withdraw/deposit
Scan QR code
Display Bank number
Complete transaction
One part of this project stood out as genuinely new territory: designing the ATM screen itself. Unlike the app, the ATM display came with a strict set of rules — limited color palette, prescribed font sizes, and fixed layout zones — all set by the ATM vendor and shaped by regulatory requirements. There was no design system to lean on, no mobile conventions to borrow from. Every decision had to be negotiated with the vendor through multiple rounds of back-and-forth, checking what was technically possible versus what the regulations allowed.
It was my first time designing a screen that wasn't a phone or a computer. What that forced me to do was strip the design back to its bare essentials, when you can't rely on familiar UI patterns or visual flexibility, information hierarchy becomes everything. The goal was simple: a user glancing at the ATM screen mid-transaction should immediately see what they need, their balance, the fee, the limit, and nothing else.
We launched to 10–20% of users in beta. The data looked promising — until it didn't.
We discovered that 55% of beta users weren't following the expected flow.
Instead of selecting a service in the app first, they started at the ATM and used the app's general scan feature to pick up from there. The problem: the app had no way of knowing which service they'd selected on the ATM side, which caused errors we couldn't even explain clearly to users when things went wrong.
I'll be honest — this caught me off guard. We had mapped the flow carefully, tested it with real users. But what we tested was the flow as designed, not the flow as people actually behaved in the wild. Standing at an ATM, it turns out, a lot of people just start with what's in front of them.
I worked closely with engineers to find a solution that didn't require users to change their behavior. What we landed on was a condition check: if a user hasn't linked a PayPay Bank account, the app infers they're going for an e-money top-up and routes them there automatically. No extra steps, no error message — the system meets users where they actually are, not where we assumed they'd be.
Adding tutorial ballon
Before
Adding progress indicator
Results
The feature launched to full production after beta. Across the three metrics we set out to move:
12%↑
Services adaption rate
16%↑
Trasaction success rate
13%↓
Customer service inquiries
The numbers held up, but what stayed with me more was the 55% we found mid-launch. That single data point changed how I think about design validation.
During the iteration, I also came up with some ideas for future improvements, such as:
Add a haptic feedback to reinforce that the number input was successful.
Retrieving data from the ATM via API after the transaction is completed, displaying the success status and amount on the screen to provide user clear feedback
Three things I'd carry into the next project:
Ask the uncomfortable question early. The behavior mismatch we found in beta wasn't unforeseeable, it was a question nobody asked until it was a live problem. Now I push harder upfront: "What happens if users don't follow the designed flow?" is a boring question until it becomes a launch-blocking one.
Multi-device means multi-context. The ATM and the app aren't just different screens, they're different environments, different mental states, different levels of time pressure. I learned to map those context shifts explicitly, not assume that a decision that felt right on mobile would hold up when someone is standing at an ATM with a queue behind them.
No amount of controlled testing fully replicates real-world behavior. The most important research in this project happened after we shipped.
Brand New Notification Center
