I designed the Get Virtual Card experience for a fintech product helping immigrants navigate international payments and financial services — from the first explanation screen to secure, authenticated card access.
MoveFinance (publicly launched as Reeple.ai) helps immigrants manage financial needs — international transfers, credit, and loans — in a system that often isn't built with them in mind.
I designed the Get Virtual Card experience: the flow that lets a user request, understand the cost of, and securely access a virtual card for online transactions. I worked alongside senior product designers and the wider product team, and owned this flow from research through to handoff.
For someone navigating a new financial system, getting access to financial products can already feel complicated.
MoveFinance was built to help immigrants manage the financial needs that come with settling somewhere new — international transfers, credit, loans. As part of the product, users needed a way to get a virtual card they could use for online transactions without needing a physical one.
The brief wasn't simply "design a card screen." It was a set of open questions the product team needed answered: what does a user need to know before getting the card? What information should they provide? What choices should they be able to make? How do we make fees and funding information clear — and how do we protect sensitive card details once the card exists?
The goal was to make the experience feel simple enough to use and transparent enough to trust.
“The interface wasn't designed to hide the complexity of the product. It was designed to organise that complexity around the user's decisions.”
What does a user need to know before getting the card, and what information are they actually expected to provide? Neither was obvious from the raw product requirement.
Fees and funding information had to be clear before a user committed — not buried in a settings page or discovered after the fact.
The card needed to be genuinely useful for everyday online transactions, without exposing sensitive credentials — PAN, CVV, expiry — by default.
The wider product team's research involved conversations with people navigating unfamiliar financial systems — particularly immigrants dealing with credit, transfers and financial services for the first time. I drew on that research to understand where users experienced confusion, uncertainty and mistrust, and to shape the virtual-card flow specifically.
Users didn't need less information — they needed it explained in language that didn't assume prior financial literacy.
Lead every step with plain-language context before asking for a decision — starting with why the card is useful at all.
It wasn't that the process was hard. It was that users couldn't predict what came next, so they hesitated rather than risk a mistake.
Make the next step and its consequences visible at every stage, especially before anything irreversible happens.
Friendly copy didn't build trust on its own. Seeing real costs and terms before confirming did.
Surface fees, funding source and terms in a dedicated review step — before card creation, not after.
Give users access to a virtual card they could use for online transactions. That was the whole requirement.
Turning it into an experience meant accounting for everything between "user has no card" and "user is confidently using one" — KYC context, application, card selection, fees and funding, creation, and secure ongoing access. The challenge was keeping all of it understandable without the process feeling like a financial form.
Rather than starting from individual screens, I started from the information a user needed at each stage — then let the screens follow from that.
A simple, guided flow for getting a virtual card. Introduce the card, explain a few benefits, confirm the one-time charge, and let the user create it. Keep it short.
The flow was too vague. The screens told users what they could get, but not enough about how it worked, what they were agreeing to, or what choices they had. The charge appeared before users had enough context to understand why they were being charged — or what would happen next.
For users already cautious about financial products, the interface was asking them to trust before giving them enough information to do so. The simplicity was actually creating uncertainty.
We moved from a "quick creation" approach to a more transparent flow that gave users more control and context before committing. Instead of rushing toward card creation, the revised experience explained the requirements, surfaced the relevant choices and made the consequences of each decision clearer.
The lesson: reducing steps isn't always reducing friction. Sometimes, clarity is the friction remover.
This wasn't a 0→1 design system. It was 0→1 inside one that already existed.
MoveFinance's visual and component system belonged to the wider product — under NDA, so the specific tokens aren't shown here. My job was to work fluently inside those constraints: apply existing components and patterns to a flow that hadn't been designed yet, and flag where the card experience needed something the system didn't have.
The first screen introduces the virtual card and gives users a reason to continue, highlighting:
Before asking users to complete a financial process, I wanted the experience to establish what they were getting and why it was useful.
Users chose between the available card options based on how they intended to use the card — presented together with contextual information, not buried in settings.
The choice should be understandable from how the user intends to spend, not from understanding the underlying financial system first.
Before creating the card, a review step showed the details that actually mattered:
Financial products have a particularly high cost of ambiguity. Users needed to see the important information before confirming, not discover it after the card existed.
The trade-off: this makes the flow slightly longer. Here, transparency mattered more than removing every possible step.
Once the card was created, the success state confirmed what had happened and pointed to a direct next action: View Details.
The user had just completed a financial action. The interface needed to clearly communicate success and immediately point them toward the next useful step.
Once the card existed, users could access their card info from the card area. Sensitive details — PAN, CVV, expiry date — sat behind an authentication gate rather than being freely exposed.
Convenient enough to use online, but convenience shouldn't mean displaying sensitive financial credentials openly.
The final experience looks relatively simple. That simplicity came from deciding what the user actually needed to see at each point in the journey.
Each option explained its intended use, reducing the financial knowledge a user needed before choosing.
Fees and funding surfaced in a dedicated review step — slightly longer, but fully informed.
Accessible from the product, but sensitive credentials required authentication first.
Not every technical detail — just enough for the user to make the next decision confidently.
I don't design in a vacuum.
The completed experience was handed over to the wider product team for implementation. I worked within a team that included senior product designers and other product contributors, translating the flow into high-fidelity designs and interactive prototypes engineering could build from.
The product subsequently launched as part of MoveFinance / Reeple.ai.
I handed this work over before post-launch measurement, so I don't attribute live-product performance metrics to it. What I can confidently show is the design work, the research behind it, the decisions I made, and the resulting product experience.
Where do users abandon the process?
How many eligible users who begin the flow successfully create a card?
How long from starting the flow to having a usable card?
How many newly created cards actually get used?
Can users retrieve their card information without needing support?
This was one of my first chances to design a fintech feature 0→1 — and the biggest lesson wasn't about designing a virtual card.
It was understanding that financial UX is often a problem of clarity and trust. A user may be perfectly capable of completing a form or tapping a button — the harder question is whether they understand what they're agreeing to, what their money is doing, and what happens next.
A simpler interface isn't necessarily one with fewer elements. It's one where the user doesn't have to work unnecessarily hard to understand what they're being asked to do.
Reducing friction isn't always about removing steps. Sometimes the better solution is making the next step obvious — even if it takes one screen more.
Trust in a financial product isn't built with reassuring copy. It's built by showing real numbers before asking someone to commit.
Testing and research kept pointing to the same things: clear language, visible requirements, visible costs, fewer surprises.
Using real user research to understand financial confusion and trust barriers.
Turning a product requirement into a complete virtual-card experience.
Structuring the flow around user decisions, not individual screens.
Balancing simplicity, transparency and security.
Working alongside senior designers and the product team through to handoff.