BYTEWALLET · FINANCIAL TRANSACTIONS
When a financial app creates doubt, users don't retry. They leave.
ByteWallet served people buying Bitcoin through physical ATMs, many using a crypto wallet for the first time. I redesigned the send flow to reduce hesitation during irreversible transactions by improving hierarchy, wallet clarity, and transaction confidence.
ROLE
Sole Product Designer
FOCUS
Send Flow · Trust · UX
PLATFORM
iOS / Android
CONTEXT
Fintech / Crypto Wallet
CONTEXT
First designer in six years.
I was the first designer in ByteWallet’s six-year history. There was no established design system, documented flow architecture, or consistent visual language across the wallet experience.
Priorities shifted frequently across the wallet, merchant POS system, investing widgets, and rewards features, often competing for the same engineering bandwidth.
So I stopped leading with design principles and started leading with what was breaking: support patterns, transaction hesitation, and moments where users lost trust.
So I stopped leading with design principles and started leading with what was breaking: support patterns, transaction failures, and moments where users lost trust.
PROBLEM
Confusion in a financial app doesn't just frustrate. It costs.
A significant portion of ByteWallet users arrived through ATM placements across the US. A physical machine handed them a receipt and sent them into a crypto wallet with little onboarding, unfamiliar terminology, and irreversible transaction behavior.
Four friction patterns consistently surfaced across the send experience.
01
The product assumed crypto literacy
Terms like network fee, gas fee, and UTXO appeared with little explanation. First-time users had no framework for what they meant.
02
Balances felt inconsistent
When users pressed Max, the sendable amount could be lower than the visible balance. The product did not explain fee deductions, asset-specific balances, or live value changes.
03
Confirmation created doubt
The final screen felt dense and overly technical at the highest-risk moment. Users paused, reread, and second-guessed themselves before sending.
04
Errors had no recovery path
When something failed, users hit generic error states with no cause, retry path, or next step. Many went straight to support.
UNDERLYING
The home screen was being built for a user the product didn't yet have.
Merchant POS signup, real estate investing widgets, a crypto news feed, a Sats rewards program. All competing for attention on the same screen as the core wallet. Someone who just walked up to an ATM, bought Bitcoin for the first time, and downloaded the app was being asked to navigate a product that didn't know what it was for. The core flows were broken while the home screen kept growing. That tension shaped every decision I made.
1
Jargon with no context
"UTXO" and "Gas Fee" appear with zero explanation. No tooltip, no help text.
1
MAX ≠ balance
Balance shows 0.0900 BTC. MAX returns 0.0821 BTC. No fee shown. No explanation. User sees a number that doesn't add up.
3
Warning reopens decision
Legal-tone copy creates hesitation at the worst possible moment. Highest abandonment point in the original product.
4
Dead-end error state
No error type, no cause, no retry CTA. Users abandoned or called support.
SUPPORT SIGNAL
The Max button exposed the trust problem.
Max confusion became one of the clearest signals that the send flow was not just visually unclear. It was breaking financial trust.
RECURRING SUPPORT PATTERN
"I pressed Max and the number wasn't what I expected. I don't understand why it's showing me a different amount than my balance."
The interface required users to mentally calculate network deductions and balance logic the product itself never clarified.
DESIGN APPROACH
Reducing hesitation inside irreversible actions.
Before redesigning the flow, I audited where users hesitated, reread, abandoned, or lost confidence. The issue was not visual polish. It was uncertainty during irreversible financial actions.
That shifted the design goal away from aesthetics and toward reassurance, clarity, and decisiveness.
My signal came from support patterns, app store reviews, transaction friction points, and direct collaboration with the people handling customer issues daily. Every screen was evaluated through a simple question:
Does this screen close the decision the user already made, or does it reopen it? Anything that introduced new doubt got cut.
✕ REJECTED — CLINICAL
"Please verify all transaction details before authorising. This action cannot be reversed once submitted."
Introduces legal anxiety. Reopens the decision.
✕ REJECTED — CLINICAL
"Review carefully. Crypto transactions are irreversible. Make sure the address and amount are correct."
Forces re-examination. Creates hesitation at the worst moment.
✓ CHOSEN — REASSURANCE
"You're sending 0.048 BTC to [address]. Network fee: $3.20. Tap to confirm."
Closes the decision. States facts. No new questions asked.
KEY DESIGN DECISIONS
Four decisions. Each one a tradeoff.
DECISION 01
The user shouldn't have to do math the product can do
I added a pill-shaped Max button, high-contrast and visually distinct from the amount input, that triggers a modal explaining exactly what was deducted and why. The review screen then shows the fee as an explicit line item, formatted the same way a bank statement shows a wire fee. The user never has to calculate.
Fee calculation is async from the network layer. I designed three modal states: loading, resolved, and error.
Solid red pill makes MAX unmissable against dark keyboard
Modal explains fee in plain language at the moment of confusion
Network fee surfaces again as line item on confirm screen
DEFAULT STATE
MAX TAPPED + MODAL
FIGMA DELIVERABLE — MAX BUTTON STATES · MODAL · FEE LINE ITEM · ANNOTATIONS
DECISION 02
Funding and sending are different jobs. They should feel different.
FIGMA DELIVERABLE — FLOW COMPARISON · BEFORE/AFTER STRIPS WITH ANNOTATIONS
The problem: confusion at one step bled into the next. A user who didn't understand "network fee" on the funding screen arrived at the amount input already doubtful. That doubt compounded at confirmation. I separated the flows so each decision could be made cleanly. The tradeoff was a longer overall journey. I accepted that tradeoff because completion rate matters more than session length in a transaction flow.
DECISION 03
Friction at confirmation. Nowhere else.
The redesign leads with the transaction summary in plain language: who, what, how much. Then the fee line item, then a single primary CTA: "Confirm Send." Compliance language moved to a collapsible secondary section. The screen closes the decision. It doesn't reopen it.
Engineering wanted compliance text on every screen. I showed alternative flows with the same information placed after key actions instead of before them. We aligned on a collapsible section on the confirmation screen, legally covered, not leading the decision.
BEFORE
AFTER
FIGMA DELIVERABLE — CONFIRMATION SCREEN BEFORE/AFTER · ANNOTATED HIERARCHY
DECISION 04
Balance visibility created unnecessary cognitive load.
BALANCE VISIBILITY: WHERE IT APPEARS AND WHY
FIGMA DELIVERABLE — FLOW COMPARISON · BEFORE/AFTER STRIPS WITH ANNOTATIONS
The original design surfaced the user's balance on nearly every screen. The intent was transparency. The effect was ambient financial anxiety. Seeing your balance update while selecting a recipient or choosing a fee tier adds cognitive load without adding value.
I surfaced balance at exactly two points: amount entry, where it directly informs the decision, and the final review, where it confirms the transaction won't overdraft. Removing it everywhere else was pushed back on internally. I countered that control comes from relevant information at the right moment, not from constant information.
THE FLOW
Predictable. Calm. One thing at a time.
1
2
3
4
5
6
7
8
Wallet overview
Select wallet
Choose recipient
Enter amount
MAX + fee modal
Confirmation
← intentional friction
Processing
Success
DEFENDING THE PRODUCT
The biggest threat to the product wasn't a design problem. It was a strategy problem.
ByteWallet was expanding faster than its core experience was stabilizing.
Merchant POS flows, investing widgets, rewards systems, and crypto news features continued growing while basic wallet actions still created hesitation for first-time users.
The product was optimizing for expansion before it had fully earned user trust.
✕ SHIPPED — HOME SCREEN & NAV AS DELIVERED
Home
Globe
Send
ATM
Wallet
HOME SCREEN SECTIONS
Portfolio Balance
✓ core
Portfolio Balance
✓ core
Portfolio Balance
✓ core
Merchant (POS signup)
✗ wrong user
Investing / Real Estate
✗ wrong user
Sats Program
✗ wrong user
Byte News feed
✗ not requested
Customize Feed
✗ placeholder text in production
8 sections competing for the same screen. One section had placeholder text live in the App Store. The user trying to send crypto could not finish a transaction.
✕ PROPOSED — FOCUSED HOME & NAV
Home
Wallet
Send
Transactions
ATM Locator
HOME SCREEN SECTIONS
Portfolio Balance
✓ core
Receive / Send
✓ core
Recent Transactions
✓ closes anxiety loop
3 sections. One user, one job. Sent money → check it landed → find ATM.
“At some point, the wallet stopped feeling optimized for sending money.”
— Former teammate during review
POST LAUNCH SIGNALS
No formal analytics. Real signals.
No formal analytics stack existed during the redesign. There was no funnel instrumentation, session replay tooling, or structured A/B testing.
So I defined success through the signals the team did have access to: recurring support patterns, transaction hesitation points, app store sentiment, and direct feedback from the people handling customer issues daily.
One pattern changed immediately after the redesign: the recurring Max button support complaints stopped surfacing.
"The quicksend was just better. Easy to find, better visibility for such an important feature. Better flow, shorter steps, better customer experience."
ON THE SEND FLOW REDESIGN
"Our customer base was indicating ages 40 to 65. Why are you going to try and fit 7 different main functions into one app? It's going to confuse them."
ON THE SCOPE EXPANSION DECISION
"It all felt like one cohesive design. It looked like thought was put into every aspect: the quicksend, scanning QR codes, entering the address, all well thought out."
ON DESIGN SYSTEM CONSISTENCY
"The product wasn't even a wallet anymore. It was losing sight of its main functionality. To act as a non-custodial wallet for beginners. That should have been the one goal. Nothing else should have mattered."
ON PRODUCT IDENTITY
3.6★
App store rating at time of writing
Up from approximately 2.8–3.0 when I joined. Negative reviews before the redesign consistently cited confusion completing basic transactions. The exact flows I was redesigning.
↓ tickets
Max button support tickets resolved
That ticket wasn't a one-off. It was a recurring category. Users couldn't understand why the maximum sendable amount didn't match their visible balance. After the fix my coworker who handled support confirmed it had stopped coming in. We didn't have formal analytics. What we had was the complaints stopping.
+ too many fucntions
Competing priorities diluted the core flow
Wallet, merchant POS signup, real estate investing, Sats rewards, ATM locator, news feed, customizable feed. The Customize Feed section shipped to production with placeholder text inside it. Not a draft. Live, in the App Store.
1 goal
What the product should have been
"A non-custodial wallet for beginners, with minimal friction, integrated with ATM machines across the US. That should have been the one and only goal." Former colleague, post-project debrief.
REFLECTION
What I'd validate next.
01
The processing state deserved more investment.
The wait during a financial transaction is where anxiety peaks. A spinner is not enough. The processing state needed visible progress, transaction status clarity, and reassurance that the transfer was still moving forward.
02
Every error state needed a specific recovery path.
"Something went wrong" is not recoverable for someone who just tried to send real money. Network timeout, insufficient balance, and address validation failures each required their own explanation and recovery path.
03
I should have tracked every concession in writing.
The progress indicator, the fee tooltip, the error specificity. I conceded these verbally in dev syncs and lost track of them. A solo designer without a PM needs to own that paper trail.
03
Work that didn't make this case study
Seed phrase onboarding, wallet organization and asset display, and a wallet cards feature: individual customizable cards per wallet with name, color, and gradient. That work lives in Figma.
In financial products, how someone feels mid-transaction determines whether they finish it. That's not a soft concern. That's the whole job.
In financial products, how someone feels mid-transaction determines whether they finish it. That's not a soft concern. That's the whole job.
What shipped was stronger than what I inherited because I learned which concessions reduced friction and which ones weakened trust. ByteWallet was the first product I designed independently with real money moving through it and users who had no fallback if something went wrong. That changed how I think about product design. I don't design for the happy path first.