Mesh | amy lu

aug 2026

crypto deposit for kalshi

Context & Role

In August, we were looking into enhancements to Mesh's deposit product for Kalshi, a prediction market and one of our clients. Kalshi users fund their accounts by depositing crypto from a wallet or exchange through Mesh, so this flow is the first moment money actually moves for them. I worked with 2 PMs to revisit the existing deposit experience and establish a clearer baseline for the product. This exercise simplified the experience, clarified the relationship between tokens and funding sources, and created more consistency across wallets and exchange flows.

Deposit flow: choose a funding method, select a wallet or exchange, enter an amount, and review fees before confirming.

Key decisions

Focus on enter amount
The original Enter amount screen asked users to keep track of two different token controls at once: a token chip at the top showing USDC on Base, and a “Funded by ETH” row at the bottom. A progress stepper sat above both. It was very unclear which token was actually funding the $24 deposit?

I collapsed these into a single Funded by control and removed the stepper, giving the screen one clear job: enter an amount. The amount now sits front and center with its max, the funding source is one clearly labeled row beneath it, and the button reads "Review deposit" instead of "Review" so users know what comes next.

Old enter amount screen with multiple funding controls — Old: Enter amount with multiple funding controls.

New enter amount screen focused on a single amount — ✅ New: A focused experience for entering an amount.

Key decisions

Make token selection consistent across wallets and exchanges
The original Choose a token screen displayed every token a user held across every chain in one long list. Tabbed filters, redundant “converted before deposit” labels, and competing information made the experience difficult to parse. There was also a fundamental ambiguity in the UI: users had to distinguish between the token they were selecting and the network it was on, while simultaneously understanding how conversion would work.

I replaced this with a compact Funded by sheet that adapts to the source of funds. For wallets, where users select a single token, the sheet uses radio buttons. For exchanges, where multiple tokens can be combined to fund a deposit, users can select multiple tokens with checkboxes, each capped at its available balance. In both cases, a persistent Total funding amount shows exactly how much will be used, so users never have to calculate it themselves. The underlying flows work differently, but the interaction pattern stays consistent: users choose what will fund the deposit, and the UI clearly shows the resulting total.

Old choose a token screen across tokens and networks — Old: Choose a token across multiple tokens and networks.

New single-token selection for wallet funding — ✅ New: Single-token selection for wallet funding.

New multi-token selection for exchange funding — ✅ New: Multi-token selection for exchange funding.

jul 2026

fiat onramp

Context & Role

Mesh is a crypto payments infrastructure company connecting wallets and exchanges to enable seamless transfers between them. I joined as Senior Product Designer, working on the 0→1 full onboarding experience for a brand-new fiat onramp and offramp product. As the solo designer on this surface, I owned the end-to-end flow design — from account creation through KYC verification, bank transfer instructions, and transfer status — partnering closely with product and engineering to take the concept from early framing to a final product.

Beyond being 0→1, the timeline was extremely tight. I designed the full stepped flow in 2 days. KYC verification itself was handled by an external partner, which meant designing a handoff that felt seamless and trustworthy even though Mesh didn't control that part of the experience directly (the user shouldn't feel like they've left the product, even when the underlying verification is happening somewhere else). On top of that, the flow needed a transfer-pending state, since bank transfers don't resolve instantly, and first-time crypto users needed to feel confident their money was safely in motion, not lost.

Stepped mobile flow covering KYC verification, bank transfer instructions, and a transfer pending state.

Designs

Breaking down the design iterations for the most important pages starting with the Buy amount screen. The first version put everything on one screen: payment methods, a fee breakdown, and a total. It was complete, but the user had to take in a lot before they’d typed a number. I removed the quick-amount chips, and consolidated the caret interactions into a bottom sheet, keeping amount entry front and center.

Earlier buy screen with payment details expanded inline — Old: Tapping a caret expanded the content inline.

Buy amount screen with the keypad and quick-amount chips removed — ✅ New: Removed quick-amount chips and clicking the carets opens a bottom sheet.

Buy amount screen with the fee breakdown in a bottom sheet — ✅ New: Removed quick-amount chips and clicking the carets opens a bottom sheet.

Designs

This is the screen where we show bank transfer instructions for the user. They need to copy the payment details into their own banking app within the time window, so clarity matters most here. After 3 iterations, I landed on a cleaned up design where there is more visual separation from payment instructions and view order details. The timer also moved up next to the transfer icon so that real estate is reserved for payment instructions, without needing to scroll.

Earlier bank transfer screen with a progress bar and a less prominent timer — Old: Unclear heading & description. Timer lacks visual prominence.

Refined bank transfer screen with clearer instructions and order details — Old: Removed the progress bar, refined the copy, and improved the visual hierarchy between instructions and order details.

Final bank transfer screen with the timer in a pill beside the transfer icon — ✅ New: Moved timer into a pill so that users can view payment instructions without scrolling.

Designs

Bank transfers aren’t instant. After the user sends the money, our system has to perform a check on the backend verifying the money arrived, and only then would they initiate the crypto deposit into their account. So there may be a gap of time that elapses, and this screen has to communicate that. The redesigned transfer pending screen communicates the expected timeline for when the crypto will arrive in the user's account. It also reassures users that they can safely close the modal and don't need to keep it open while the transfer is being processed.

Earlier transfer pending screen that still showed the timer and payment instructions — Old: Unclear whether the timer and instructions still apply in this state.

Transfer pending screen with an updated icon and copy — Old: Updated icon and copy.

Transfer pending screen with a timeline for when crypto arrives — ✅ New: Added a clear timeline showing when the transfer is expected to complete.

Designs

A fiat-to-crypto transfer involves real money moving through an external bank rail (SPEI), which meant failure wasn't an edge case to handle later, it was a core part of the experience from day one. I designed a set of distinct failure and recovery states, each with its own specific message and next action, rather than a single generic error screen:

Identity verification failure
Since KYC was handled by an external partner, users needed a clear path forward even when that handoff didn't resolve cleanly: retry, or view an FAQ for more context, rather than a dead end.
Payment confirmation
since SPEI transfers happen outside the app, in the user's own banking app, this drawer appears when a user taps the "x" to close the payment instructions screen, prompting them to confirm whether they'd actually sent the transfer before letting them leave the flow. If they'd sent it, they could confirm with "I've sent the payment"; if not, they could cancel the order instead. This closed a real gap: without this check, a user could back out of the flow mid-transfer with no record of their intent, leaving Mesh unable to distinguish an abandoned order from a completed one still in flight.
Transfer window expiration
SPEI quotes are time-bound, so if a user didn't complete their bank transfer in time, the payment details were no longer valid. Rather than leaving them stuck on a dead quote, the flow explained what happened and gave a direct path to re-enter the amount and get a fresh quote.
Generic purchase failure
A fallback state for failures that didn't fit the more specific cases above, reassuring users that any funds received would be returned, with a direct path to contact support.

Identity verification failure screen — 1. Identity verification failure.

Payment confirmation screen — 2. Payment confirmation.

Transfer window expiration screen — 3. Transfer window expiration.

Generic purchase failure screen — 4. Generic purchase failure.

jul 2026

fiat offramp

Extending the buy framework for withdrawing crypto to cash.

Stepped mobile flow covering KYC verification, bank transfer instructions, and a transfer pending state.