Consumer Wallet
& Payments App
Overview
REU Personal was RYVYL EU's personal payment account for European consumers: multi-currency checking, physical and virtual cards, card controls, tokenized payments, and fraud detection in one app.
Consumers used it to move money across borders, manage multiple currencies, and control their cards without calling a bank.
I designed it end-to-end as UX Designer II, from discovery through high-fidelity delivery, working alongside a VP of Product Development, a Director of Design, two PMs, and a UX Writer. Working across that many stakeholders meant navigating disagreements on feature scope and navigation structure. I used card sorting, first-click testing, and A/B testing to align the team rather than letting it stall.
No consumer-facing app existed in the REU branch before this project. RYVYL built REU Personal to generate a new revenue stream alongside the B2B product line. Building the B2B product line meant solving multi-currency payments in depth: payment rails, edge cases, regulatory requirements. We applied that foundation of knowledge to build REU Personal.
Problem & Goals
Legacy banks in Europe handled cross-border payments slowly, buried card controls, and showed users no real-time view of pending transactions. Feature usage data, card sorting, and first-click testing during IA validation surfaced where the friction concentrated:
- Managing multiple currencies required too many steps
- Card controls were hard to find
- Pending transactions and holds weren't visible until they cleared
- Users didn't trust non-bank products with their money
- Dispute and fraud reporting gave no status feedback after submission
The scope: multi-currency checking, physical and virtual debit and prepaid cards, fund transfers, tokenized payments, and granular card controls, all meeting EU regulatory requirements.
Process
Zero-to-one means committing to foundational decisions before you have enough data to validate them: information architecture, navigation model, account hierarchy, and how to surface multiple card types without losing users. I validated those decisions in wireframes before committing to hi-fi. Bad IA found in wireframes costs a day to fix. In hi-fi, it costs a week.
Usage data from discovery showed what users opened every day and what they skipped. Balance checking and transaction history led by a wide margin. Transfers came in frequent but below expectation. Bill pay and card controls ranked at the bottom.
Key Insight: High-frequency features needed the shortest path and primary placement. Low-frequency features needed to stay reachable without taking up primary surface space.
Fitts's LawSerial Position Effect Frequency data made placement concrete: balance checking and transfers — the two most-used features — got the shortest paths and primary nav positions. Lower-frequency features stayed accessible without occupying primary surface space.
Key decisions that shifted across 3 rounds:
- Navigation hierarchyJakob's Law: card sorting confirmed users expected a familiar banking hierarchy — accounts primary, cards nested beneath. Restructuring to match that mental model improved navigation accuracy by up to 35pp.BeforeAccounts and cards as siblings at equal hierarchy — no clear indicator of which to tap for whatAfterAccounts as the primary surface, cards as a child, prepaid cards as a separate category — matching the user's actual mental model
- Transfer flowBefore6-step process: select account, select payee, enter amount, transfer type, note, review — each step holding only one or two inputsAfter2 pages — payee first; eligible accounts and transfer types are filtered to only what applies, reducing errors and confusionMulti-step flows create paced commitment and cleaner error recovery, but when steps are genuinely simple, the extra navigation is overhead, not structure.
- Authentication entryPostel's Law: a single phone number field accepts ambiguous intent and routes to sign up or login automatically — the system handles the branching, not the user.Hick's Law: eliminating the sign up vs. log in decision also reduces the time until task completion.BeforeEmail-based login with separate sign up and log in screens — users had to choose a path before they'd even startedAfterSingle phone number field; routes to sign up or login automatically, reduces screens to value, and simplifies two-step authentication since the verification channel is already established
- Onboarding flowGoal-Gradient Effect: a single action button per step makes each increment of progress visible, accelerating completion as the end approaches.BeforeNo guided entry — new users landed on the home screen with no clear starting pointAfterA guided onboarding flow with a single action button to step through setup; users who skip it see persistent recommended action cards on the home screen they can return to at any time
Outcomes & Results
REU Personal never shipped. RYVYL ceased operations before the product reached production. I structured navigation around the usage data: balance checking and transfers, the two most-used features, got the shortest paths and primary placement. Prepaid cards stayed reachable without cluttering the main surface.
Each pain point from discovery had a direct design response:
- Multi-currency balances on the account overview, visible on first open
- Card controls on the card detail surface as primary actions, one tap from anywhere in the card flow
- Pending transactions and holds in the account overview, updating in real time
- Fund protection messaging in the authentication flow, addressing distrust before the first transaction
- Dispute and fraud flows with inline status updates and a clear resolution path
Learnings: Running card sorting and first-click testing before hi-fi cut rework that would have taken two to three weeks. Usage data made prioritization concrete: a rank-ordered list of what users actually opened, not a judgment call about what seemed important. Scope control mattered as much as design quality. We cut the following features from v1 scope: scheduled payments, budgeting, savings, visual charts, and investments. None had enough demand signal in discovery to justify the implementation cost. I advocated for currency exchange and conversion: both had demand signal and fit a multi-currency app. Both were cut from v1 due to engineering complexity and timeline.
