ROLE: Visual Interaction Designer
Duties:
UX design, interaction design, user flows, prototyping
PROBLEM
Checkout is where digital commerce breaks. Users hit a wall: re-enter card details they already gave somewhere else, remember a password they've forgotten twice, trust a payment processor they've never heard of. All friction. All anxiety. All abandonment.
From the user side, it's brutal:
Same card details entered over and over across different stores
Password fatigue that makes people give up before they buy
Security signals that don't actually signal anything — just noise that increases doubt
From the business side, the cost is real: lower conversion, longer checkout time, users who don't come back.
The ask: could a bank-backed digital wallet actually reduce that friction without becoming another account to manage, another thing to learn?
SOLUTION
Paze is built on a simple idea: stop treating payment like a separate problem. Make it automatic. Make it biometric. Make it feel like something the bank is doing for you, not something a startup is selling to you.
Three things had to happen:
Cards show up automatically through the banks users already trust
Biometrics replace passwords — no remembering, no resetting
Checkout becomes a series of clear, minimal choices instead of a gauntlet of forms
The goal wasn't speed for speed's sake. It was to make payment feel inevitable. Fast, familiar, done. That's what kills both cognitive load and the anxiety that makes people abandon carts.
ENTRY POINT
The entry point had one job: kill hesitation. Before asking users to authenticate, the experience had to answer three things clearly:
This is bank-backed. Not another third-party service. Not another middleman. The institution users already trust, handling payment.
No passwords. Biometrics. That's it. Faster, more secure, and it removes the single biggest friction point in digital transactions.
This is safe. Not through jargon or security badges. Through clarity. Through showing exactly how authentication happens, so users know what they're agreeing to.
This flow treats reassurance as a feature. It answers the questions before users have to ask them, reducing drop-off at the moment that matters most — when someone's about to hand over their money.
ADDING A CARD - FLOW
Adding a card shouldn't feel like a commitment. Most wallet flows make it feel like one — you're filling forms, confirming permissions, entering data that could be wrong. This flow strips all that out.
What mattered:
Show eligibility upfront. Don't let users get halfway through and hit a wall.
Minimal typing. If the bank knows the card, don't ask for it again.
Make it clear the user owns this. They can add it, remove it, ignore it. It's theirs to control.
The whole thing is designed to feel reversible. Optional. A tool you can pick up and put down without consequences. That's what makes people actually use it instead of abandoning it halfway through.
REMOVING A CARD - FLOW
Removal flows get ignored in design. That's a mistake. How easy it is to leave tells users everything about whether they can trust staying.
This one does three things:
Shows exactly what's being removed. No ambiguity. No surprise.
Asks for confirmation. Not aggressive — just clear. "This is what's going away."
Gives feedback immediately. The card is gone. The user knows it worked.
Easy exit means real confidence. It means the user isn't trapped. And when users know they're not trapped, they actually engage with the tool instead of treating it like something being forced on them.
ERROR STATES
Payment fails. Systems go down. Cards get declined. When that happens, the user is stressed. The experience needs to handle that stress, not add to it.
These error states do the work:
Explain what actually happened in plain language. Not "authentication failed" — what that means to the user.
No technical noise. No warnings that sound like alarms. Just clarity.
Show the next step. Don't make users guess what to do or restart from scratch.
This is about recovery, not blame. The user didn't do anything wrong. The system did. Tell them that, tell them how to fix it, and let them move forward. That's what builds trust when things break.
OUTCOME
This is what happens when you design payment around how people actually think, not around feature checklists.
The metrics that matter: checkout abandonment drops, people finish faster, and they come back. They actually use the wallet instead of ignoring it. But the real win is subtler — users stop treating the wallet like a risk and start treating it like a tool.
And that's the whole point. When trust, speed, and clarity actually work together instead of competing, friction disappears. People finish the transaction. The business wins. Everyone's better off.
KEY TAKEAWAYS
Remove decisions instead of adding them. Every choice is friction.
Trust lives in transparency and reversibility. Let users undo things and they'll try things.
Security shouldn't announce itself. It should just be there, quiet and solid, never getting in the way.