BYTEWALLET · FINTECH · SHIPPED 2024
Trust at the Final Tap
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.
ROLE
FOCUS
PLATFORM
CONTEXT
CONSTRAINT
Sole designer, six-year-old product, no existing design system
DECISION
Separated funding from sending, redesigned confirmation hierarchy, mapped recovery needs across failed states
TRADEOFF
SIGNAL
The recurring MAX-button support tickets stopped surfacing after the fix shipped.
CONTEXT
I was the first designer in ByteWallet's six-year history. No established design system, no documented flow architecture, no consistent visual language across the wallet.
Priorities shifted constantly across the wallet, merchant POS, investing widgets, and rewards features, all competing for the same engineering bandwidth. I worked closely with the engineering lead to sequence what shipped when, and sat in on support call reviews weekly to catch friction before it became a ticket pattern.
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 share of users arrived through ATM placements with little onboarding, unfamiliar terminology, and irreversible transaction behavior. Four friction patterns kept surfacing.
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.
BEFORE — HEURISTIC EVAULATION · 4 FRICTION POINTS IDENTIFIED
1
Jargon with no context
"UTXO" and "Gas Fee" with zero explanation.
2
MAX ≠ balance
Balance shows 0.9821 BTC. MAX returns less. Unexplained, in the old version.
3
Warning reopens decision
Legal-tone copy creates hesitation at the worst moment.
4
Dead-end error state
No error type, no cause, no retry CTA.
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.
"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.
The issue wasn't visual polish. It was uncertainty during financial actions that couldn't be undone. That shifted the goal from aesthetics toward reassurance and decisiveness, informed by support patterns, app reviews, and direct collaboration with the team handling customer issues daily.
Does this screen close the decision the user already made, or does it reopen it? Anything that introduced new doubt got cut.
✕ REJECTED — CLINICAL
✕ REJECTED — CLINICAL
✓ CHOSEN — REASSURANCE
USER FLOW — SEND CRYPTO REDESIGNED
KEY DESIGN DECISIONS
Four decisions. Each one a tradeoff.
DECISION 01
The user shouldn't have to do math the product can do
A pill-shaped MAX button, high-contrast against the keyboard, triggers an explainer card showing exactly what was deducted and why. The fee then resurfaces as a line item on the confirm screen, the same way a bank statement shows a wire fee. The user never has to calculate.
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
DECISION 02
Funding and sending are different jobs. They should feel different.
Confusion at one step bled into the next. A user who didn't understand "network fee" while choosing a source wallet arrived at the amount screen already doubtful, and that doubt compounded at confirmation. Separating the steps let each decision get made cleanly.
The tradeoff: a longer overall journey. Accepted, 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, then one primary CTA: Send Now. Reassurance replaces warning. The screen closes the decision, it doesn't reopen it.
Engineering wanted compliance language kept visible throughout. I showed the same information placed after key actions instead of before them. The final version keeps the irreversibility notice, but frames it as confirmation rather than warning, paired with a green "everything looks correct" signal.
DECISION 04
Every error needed its own explanation and its own way out.
The original failure state was a single generic message. It didn't say what happened or what to do next. A user who just tried to send real money and hit a wall had nowhere to go but support.
I designed separate error states for separate causes. A network timeout gets reassurance that funds are safe and a retry path. Insufficient balance gets a specific explanation of the shortfall and a path to adjust the amount or use MAX. Same visual language, different message, different recovery action.
THE FLOW
Predictable. Calm. One thing at a time.
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, investing widgets, rewards, and a news feed kept growing while basic wallet actions still created hesitation for first-time users. The product was optimizing for expansion before it had earned 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
Eight sections competing for the same screen. The user trying to send crypto couldn't 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
Three sections. One user, one job: send money, check it landed, find an 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 funnel instrumentation or session replay tooling existed at the time. Success was defined through the signals available: recurring support patterns, app store sentiment, and direct feedback from the team handling customer issues. One pattern changed immediately: the recurring MAX-button complaints stopped surfacing.
EXTERNAL VALIDATION — FORMER COLLEAGUE — RECORDED POST-PROJECT DEBRIEF
"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
↓ tickets
Max button support tickets resolved
Not a one-off, a recurring category. Confirmed by the teammate handling support that it stopped coming in after the fix.
Scope creep
Competing priorities diluted the core flow
Wallet, merchant POS, investing, rewards, ATM locator, and a news feed all competing for attention.
Core job
What the product should have been
REFLECTION
What I'd validate next.
01
The processing state deserved more investment.
The wait during a financial transaction is where anxiety peaks. The shipped version shows a step tracker, signed, broadcasting, confirming, which helps. I'd still want to validate whether users trust it enough to close the app, as the copy invites them to.
02
Every error state needed a specific recovery path.
I designed for network timeout and insufficient balance specifically, since those were the two causes support saw most. Other failure modes, like address validation, still need their own dedicated path.
03
I should have tracked every concession in writing.
The progress indicator, the fee explainer copy, the error specificity. I conceded these verbally in dev syncs and lost track of them. A solo designer without a PM needs that paper trail.
04
Work that didn't make this case study
Seed phrase onboarding, wallet organization, and a customizable wallet cards feature. 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.
What shipped was stronger than what I inherited because I learned which concessions reduced friction and which weakened trust. ByteWallet was the first product I designed independently with real money moving through it, no fallback if something went wrong. I don't design for the happy path first.