Trust at the Final Tap
ROLE
Sole Product Designer
Team
Direct with engineering, no PM
Platform
Native mobile, iOS and Android
scope
Send and fund flows, component library and state specs
ByteWallet has since rebranded as ByteVault.
OVERVIEW
How do you make a transaction people can't undo feel safe enough to send in the first place?
Support kept answering the same questions about balances and fees, and the volume was growing. Every one of them was about a transaction that couldn't be undone.
I joined ByteWallet, the non-custodial, multi-asset wallet behind a Bitcoin ATM network serving thousands of users across 40+ states, as its first product designer.
THE PROBLEM
Users reached the final step without understanding the full transaction.
Support conversations and app reviews showed the same pattern: the information existed, but it wasn't clear what would actually leave the wallet.
01
Assumed crypto literacy
Jargon like UTXO, gas fee, little explanation.
02
Inconsistent balances
Max returned a lower number than shown, unexplained.
03
Confirmation created doubt
Dense, technical, at the highest-risk moment.
04
No recovery path
Generic errors, no cause, no next step.
RESEARCH
"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 clearest signal came from the Max button. Users expected it to match the balance they could already see. Instead, a hidden network deduction handed them a different number, with nothing on screen explaining why. The interface left people to reconcile two numbers and calculate a fee the product already knew.
It also knew three other numbers it never showed: how much was still confirming, how much was held after the ATM purchase, and how much this user was allowed to send today.
Exploring the Confirmation CopY
The final step had to answer questions, not create new ones.
Sending Bitcoin can't be undone. By the time someone reached confirmation, they'd already made the decision. The screen's job was to help them check it, not make them second-guess it.
My first pass leaned legal. A softer version didn't fix it either; it just repeated the risk. What actually worked was dropping the warning language and restating the facts.
FIRST ATTEMPT
“Please verify all transaction details before authorizing. This action cannot be reversed.”
STILL DIDN'T WORK
“Review carefully. Crypto transactions are irreversible.”
WHAT SHIPPED
“You’re sending 0.048 BTC to [address]. Network fee: $3.20.”
Restated the facts and introduced no new question.
KEY DESIGN DECISIONS
Four decisions that changed how sending felt.
DECISION 01
Users shouldn't calculate network fees.
There was no product manager, so I worked through the fee logic directly with engineering. They walked me through how the network fee was calculated and which parts of it were fixed. I couldn't change the number. What I could change was whether someone saw it before they committed instead of after.
Pressing Max exposed the biggest misunderstanding in the flow. Users expected it to match their visible balance, but hidden network deductions produced a different number.
→ Review stays disabled until a valid amount is entered
→ Network deduction explained the moment Max is selected
→ Fee repeats as a line item at confirmation
DECISION 02
Funding and sending are different jobs. They should feel different.
Tradeoff
One extra screen.
Fewer compounded decisions.
DECISION 03
Friction at confirmation. Nowhere else.
Adding a screen isn't the same as adding friction. Every step before confirmation asks one question and moves on. Confirmation is the only place the flow slows down, because it's the last moment anything can change.
DECISION 04
Every error needed a next step.
I split the two failure patterns support saw most often: a network timeout reassures users their funds are safe and offers a retry; an insufficient balance explains the exact shortfall.
FINAL EXPERIENCE
Each screen answered one question.
The shipped flow separates source, recipient, amount, fee review, confirmation, processing, and recovery instead of combining several decisions on the same screen.
THE HOME SCREEN
While stabilizing the send flow, the home screen kept expanding: merchant tools, investing, rewards, ATM discovery, news. All of it competed with the one thing users actually came to do after buying Bitcoin.
FORMER TEAMMATE DURING REVIEW
I proposed a restructure that led with sending and moved merchant tools, investing, rewards, ATM discovery, and news into a secondary layer, so the home screen opened on the thing most people came to do.
The home screen served a lot of teams, and the tradeoff between them was larger than the send flow. What the redesign made clear was that clarity inside a flow can be undone by the screen that leads into it.
FROM FIGMA TO PRODUCTION
Design did not stop at handoff.
There was no product manager on this, so I worked straight with engineering from the first spec through the build. I specced the states a mockup skips: the amount field when the balance updates mid entry, the confirmation screen while a transaction is pending, what each error offers as a next step.
Some of it changed once engineering came back with the limits of real time balance data, and I reworked the balance states around what the system could report. I reviewed builds before release and caught what shows up in implementation rather than in Figma: spacing, state handling and copy that did not survive the build.
OUTCOME
What changed after the redesign.
+28%
COMPLETED SENDS
More people who started a send finished it on the same flow after the redesign shipped.
−42%
SEND FLOW SUPPORT TICKETS
The Max button and available balance questions that had been steady in the queue stopped coming in.
REFLECTION
What I'd carry forward
Validate the wait.
I'd want to know whether the processing state makes people feel secure enough to close the app, not just informed about what's happening.
Document as you go.
Most of what I compromised on, like the progress indicator and fee copy, was agreed to verbally. There was no PM to track what changed and why.