Designing for the 'I don't know what I'm doing' first-time crypto user

Between February and March 2025 I ran fourteen first-time crypto user-tests as part of the Enrichplay onboarding redesign. None of the participants had ever owned crypto. None had ever used a self-custody wallet. All were recruited via X (formerly Twitter) DMs and pre-screened by phone — fintech-curious, tech-literate enough to use Robinhood or Wise, but explicitly outside the crypto bubble. Sessions ran sixty minutes each, unmoderated for the first thirty and moderated for the second thirty, recorded with Maze and Lookback.

This post is the long version of the testing round. It's a companion piece to the high-level Enrichplay design write-up; if you want the patterns without the research scaffolding, start there. If you want the raw findings and the six patterns that fell out of them — keep reading.

A first-time-user test session in progress, with a phone, a coffee, and a Figma prototype on the laptop screen

The 3 ways first-time users get stuck

Before we get to the patterns, the failure modes. Across fourteen sessions, three distinct points of breakdown accounted for roughly 80% of the abandonments we observed. Every wallet onboarding I have audited since has hit at least two of them.

The "what am I looking at" wall. The home screen of most wallets shows token balances, chart sparklines, swap CTAs, send/receive buttons, and a list of tokens the user has never heard of. A first-time user, having just signed up, has no balance, no transactions, and no context for any of it. The home screen is built for a returning power user. The first-time user sees noise and bounces.

The "I broke something" panic. A first-time user taps something they don't understand, sees a modal with red text, doesn't know whether they have lost money or are about to, and closes the app. We watched this happen in seven of fourteen sessions, on different screens, all with the same emotional shape — uncertainty, mild panic, exit.

The "this isn't for me" decision. This one is the most subtle. A user spends two or three minutes inside the product, doesn't lose money, doesn't make a mistake, and just quietly decides this is not a product for someone like them. They were not scared off. They were not confused. They were excluded by tone. This is the failure mode designers usually miss because the user does not complain — they simply leave.

The six patterns below are what we used to address those three failure modes. Each pattern is anchored to one of them, and each one carries its weight in real measurable lift on the live product.

Pattern 1 — Explain why before how

In the old wallet, the first thing the user saw after sign-up was a screen titled "Backup your wallet" with a 12-word phrase and a list of instructions. Users had no idea why they were doing this. They knew they were supposed to write something down. They did not know what the words meant, what would happen if they didn't, or what the alternative was.

One tester said it cleanly:

"I don't understand why you're showing this to me. I haven't done anything yet. What is this?"

The fix was a single one-sentence preamble before the words appeared:

"This is the only way to get your money back if you lose your phone. We'll store an encrypted copy in your iCloud, but you can also write the words down yourself if you'd rather."

That one sentence — the why — moved backup-completion rate from 43% to 78% in the next round of testing. The user didn't need a tutorial. They needed a reason.

The generalised pattern: before you ask the user to do something effortful, tell them in one sentence what the consequence is of not doing it and what the alternative is. Most onboarding skips the consequence. The consequence is the part that earns the effort.

Pattern 2 — Hide the chain unless they ask

Multi-chain support is a power-user feature. It is also the single most confusing thing on a first-time wallet's home screen. Showing "Ethereum / Polygon / Base / Arbitrum / Solana" as five separate balance lines to someone who doesn't know what a chain is produces guaranteed confusion.

In testing we watched twelve of fourteen users try to figure out which chain they were supposed to use, conclude they didn't know, and tap around until they accidentally chose one. Two of those twelve later regretted their choice and asked us "can I move it back?" — which is the wrong question to be asking thirty seconds into using a financial product.

We split the defaults by user type. The decision matrix we shipped:

The trick is that the underlying functionality is identical. The user is always operating on a chain. They simply don't have to know it. The chain becomes a thing the product handles, not a thing the user has to choose. That alone took completion of the "receive your first $5" flow from 31% to 71%.

Pattern 3 — Translate jargon at the boundary, not inline

A common bad pattern is inline definitions: "Gas (the small fee paid to process the transaction)" hovering next to every mention of the word. This treats the user like they're reading a textbook. They're not. They're trying to send money.

The better pattern is to translate the jargon at the system boundary — the layer where the user interacts with the technical reality — and then never use the jargon again inside the product. "Gas" becomes "network fee." "Transaction" becomes "send." "Approve" becomes "allow." "Mempool" stays inside the engineering team where it belongs.

The version of this rule I now apply to every wallet, fintech, or technical product I work on: if a word is jargon, replace it with the plain-language version everywhere in the UI. If you absolutely need the jargon (regulatory reasons, advanced settings), keep it behind one consistent door labelled "Advanced." Don't translate inline. Translate at the boundary.

Tester quote, when asked what "approve" meant in the old version of the wallet:

"I think it means I'm agreeing to something? Maybe a terms-of-service? I'm not sure if I should tap it."

After the boundary-translation rewrite, the same flow used "allow this app to use your USDC" instead of "approve token." Comprehension on the post-test survey went from 22% to 86%.

Pattern 4 — Recoverable mistakes vs irreversible ones

Crypto's worst UX trait is that every mistake feels potentially fatal. Sent to the wrong address — gone. Lost your seed phrase — gone. Approved a malicious contract — drained.

The reality is more nuanced. Some mistakes are irreversible. Most are recoverable, if the UI tells the user how. The old wallet treated every mistake with the same red text and the same "this cannot be undone" language. That trained users to fear every action equally — including the safe ones.

In Enrichplay we split the visual treatment by reversibility:

• Reversible actions (canceling a pending transaction, changing a preference, hiding a token) — neutral colour, no warnings, immediate
• Recoverable mistakes (sending to a contact address with one wrong character, approving an unknown token) — yellow caution, a short explanation of how to recover, no scare language
• Irreversible actions (sending to a fresh address, signing a contract approval) — red caution, a forced one-tap confirmation, plain-language description of what is about to happen and what cannot be undone

The result: the irreversible warnings became meaningful again because they were the only red warnings in the product. Users actually read them. In testing, false-alarm bounces (closing the app at a yellow warning that wasn't actually dangerous) dropped from 24% to 6%.

Pattern 5 — Don't surface fees in the obvious place

This one is counter-intuitive and I caught a lot of pushback from the founder before we shipped it. Most wallets show fees prominently at the moment of transaction — a line item with the gas cost, sometimes a slider for fast/medium/slow. The thinking is transparency.

The testing showed something different. First-time users did not understand the fee. They didn't know if 0.0001 ETH was a lot or a little. They didn't know whether the fast/medium/slow slider would lose them money. They froze. Six of fourteen users abandoned the swap flow at the fee-confirmation step, all citing the fee as the reason — but when we asked follow-up questions, none of them actually objected to the cost. They objected to not knowing whether they should object.

We did three things:

1. Showed the fee in USD, not in native token units. "Network fee: $0.42" reads instantly. "0.000124 ETH" does not.
2. Made fast/medium/slow into a single recommended default for first-time users. Power users can change it. Novices don't see the slider.
3. Showed the fee only on the final confirmation screen, not in the swap setup. Earlier in the flow the user sees a "Total cost ≈ $5.42 (incl. small network fee)" line and that's all.

Conversion through the swap flow improved 38% with no measurable change in user complaints about fees. The fee was never the objection. The cognitive load of evaluating the fee was.

Pattern 6 — Treat the seed phrase like a passport, not a password

This is the single most important pattern. Every wallet treats the seed phrase like a password — something you memorise, never share, and re-enter to log in. That mental model is wrong, and it fails first-time users.

A seed phrase is closer to a passport. It's a document. You store it somewhere safe. You don't memorise it. You don't enter it daily. You produce it when you need to prove who you are, usually because you've lost something. It is not part of routine use.

Once we made that mental model the design metaphor, the screens fell out cleanly:

• The seed phrase screen is called "Recovery document," not "Seed phrase backup."
• It is presented like an official-looking certificate, not like a password challenge.
• The default is "store this securely for me" (encrypted cloud backup with biometric unlock).
• The opt-in alternative is "give me my own copy" — and that path shows the words in a frame designed to be screenshot, printed, or written, with an explicit "this is your responsibility now" callout.
• The recovery flow (entering the words) is hidden inside "I lost access to this wallet," not surfaced as a routine login option.

Backup completion went from 43% in the old wallet to 81% in the new one. More importantly: user-reported confidence in the recovery flow — measured via post-test survey — went from 1.9/5 to 4.3/5. The passport metaphor isn't decorative. It's load-bearing.

What we'd test next

Three things we didn't get to in this round and that I'd queue for the v2 sprint:

• Social recovery as the default for users who don't have iCloud/Google Drive — particularly relevant in markets where neither service is dominant.
• In-context teach-ins that surface only when the user is about to do something for the first time. We over-indexed on hiding complexity. Some users in the second round explicitly asked for "tell me more" affordances and we didn't have them.
• Localisation testing for non-English markets, specifically Urdu, Indonesian and Vietnamese, where the abstract metaphors (passport, document, recovery) don't necessarily land the same way they land in English. This is the gap I called out in the higher-level Enrichplay design post and it's still the most important item on the backlog.

What this generalises to

The six patterns are crypto-specific in their examples and not crypto-specific in their structure. Substitute "seed phrase" for "tax forms" and you have an H&R Block onboarding. Substitute it for "consent to share medical records" and you have a telehealth onboarding. The shape is the same: a domain-expert team shipping a product for a domain-novice user and forgetting that the novice doesn't share their vocabulary, their mental models, or their tolerance for risk.

The fix is the same too: defer the scary, default to the safe-and-recoverable, write the copy like a person, separate reversible from irreversible, and pick the user's first action for them.

Related reading

• Designing crypto wallets for first-time users — the high-level companion to this post
• My UX redesign process — Take Therapy — same operating principles applied to mental-health onboarding
• What I wish founders knew before hiring their first UX designer — for founders weighing their first hire after reading research like this

See it in practice on the full Enrichplay case study, which covers the design system, the journey map, and the iteration timeline.

Building a wallet — or something equally scary?

If you are building a crypto wallet, a fintech, or any product where the first sixty seconds decide whether the user ever comes back, this is the format of work I'm sharpest at. Tell me what you're building. See how I work for the shape of the engagement.