---
title: "Web3 UX Challenges: A PM Checklist"
description: "Web3 UX challenges as product decisions: wallet connection, network switching, gas, huge token numbers, irreversible actions and block latency, with fixes."
canonical_url: "https://builderscamp.com/guides/other/web3-ux-challenges"
date_published: "2026-09-27"
date_modified: "2026-09-27"
author: "Andre Albuquerque"
publisher: "Builders Camp"
guide_class: "other"
---

# Web3 UX challenges: a product manager's checklist

**TL;DR:** The six web3 UX challenges that stop users are connecting a wallet, switching networks, paying gas, reading huge token numbers, taking irreversible actions and waiting on block confirmations. Each one forces a product decision, from who holds the keys to who pays the fee, and the team that makes those decisions explicitly ships a product people finish using.

Most web3 UX writing is about visual polish. The harder problems are product decisions that sit underneath the screens: who holds the keys, who pays the fee, and what the user sees while the chain catches up. ethereum.org's own account abstraction page says that "Securing these seed phrases is awkward, even for expert users," and names seed phrase phishing among the common scams. And the waiting is built in: [ethereum.org's proof-of-stake docs](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/) state that time on Ethereum is divided into slots of 12 seconds.

Below is a checklist per friction point, with the decision each one forces and what to put in the spec.

## Which web3 UX challenges should a product manager decide on first?

Six friction points account for most drop-off between landing page and first successful transaction. Treat them as a funnel, because each one only matters once the user has passed the one before.

| Friction point | What the user experiences | Product decision it forces |
|---|---|---|
| Connect wallet | Asked to install software and save a seed phrase before seeing value | Self-custody, embedded wallet or smart contract wallet |
| Switch network | A pop-up asking to add or switch to an unfamiliar chain | Which chains you support and whether you prompt the switch |
| Pay gas | A fee in a token they may not hold, in a unit they do not know | Who pays, and whether actions are batched |
| Read token amounts | Numbers with many decimal places, or raw integers | Rounding, units and fiat display rules |
| Irreversible action | A signature request with no undo | Confirmation design and pre-transaction checks |
| Wait for confirmation | A spinner with no explanation | Which states to show and when to call it done |

Instrument each row as a funnel step. If you already track [activation rate](https://builderscamp.com/guides/glossary/activation-rate) on a web2 product, the definition here is the first successful on-chain action, not the sign-up.

## How should a web3 product handle wallet connection?

Wallet connection is where you decide custody. [ethereum.org's wallet guide](https://ethereum.org/en/wallets/) tells users that a seed phrase must be written down somewhere safe and that it is the only way to recover the wallet. For a crypto-native audience, asking for an existing browser wallet is fine. For anyone else, it is a wall in front of your value proposition.

The options sit on a spectrum. A browser extension wallet gives the user full control and full responsibility. An embedded wallet created behind an email login removes the install step but means your product, or a vendor, is involved in key management. A smart contract wallet can add recovery through trusted devices or people, which [ethereum.org's account abstraction page](https://ethereum.org/en/roadmap/account-abstraction/) lists among its benefits. Pick one default per audience, and let people see what value they get before you ask them to create anything.

## What should happen when a user is on the wrong network?

Network mismatch is the web3 version of a broken deep link. The user connects, and your app is on one chain while their wallet is on another. Wallets expose a standard method for this: [EIP-3085](https://eips.ethereum.org/EIPS/eip-3085) defines `wallet_addEthereumChain`, which lets an app suggest that a new chain be added to the wallet's list.

The decision is how many chains to support and how hard to push. Every extra chain is another set of contracts to audit, another bridge for users to cross and another support path. Support the fewest chains your users already hold assets on. When a switch is needed, say in plain words which network and why, then trigger the wallet prompt from a button the user presses, not on page load.

## Who should pay gas fees in a web3 product?

Gas is a per-action price the user did not expect to pay. The [ethereum.org gas documentation](https://ethereum.org/en/developers/docs/gas/) explains that gas prices are quoted in gwei, where each gwei is one-billionth of an ETH, a unit almost no new user has seen before.

You have three levers. Reduce the number of transactions by batching steps and keeping non-critical data off-chain. Choose a network where fees are low enough not to register for your typical action size. Or sponsor gas, since ethereum.org's account abstraction page lists paying someone else's gas as a smart contract wallet benefit. Sponsoring works well for a first action and badly as an unlimited promise, so set a budget per user and per action, and track it like any other acquisition cost.

## How should a web3 app display very large token numbers?

Contracts store token balances as whole numbers alongside a decimals setting. The [EIP-20 token standard](https://eips.ethereum.org/EIPS/eip-20) explains the decimals function with an example: a value of 8 "means to divide the token amount by 100000000 to get its user representation." Show the raw integer and you have shown the user nonsense. Show every decimal place and you have shown them noise.

Write display rules into the spec: how many decimals to show per token, when to round, when to show a fiat estimate, and what to do for dust amounts too small to display. Never round in a way that lets a user think they can withdraw more than they hold.

## How do you design for actions that cannot be undone?

On-chain actions have no support ticket that reverses them. [ethereum.org's smart contract introduction](https://ethereum.org/en/developers/docs/smart-contracts/) states that "Smart contracts cannot be deleted by default, and interactions with them are irreversible." A wrong address, an unlimited token approval or a signature on a malicious site is final.

Design the confirmation step as a safety check, not a formality. Show the outcome in plain language before the wallet prompt: what leaves the wallet, what arrives, and at what cost. Flag the risky patterns you can detect, such as a first transfer to a new address or an approval for an unlimited amount. The trust, security and risk side of this, including scam patterns, is one of the topics a [web3 product manager](https://builderscamp.com/guides/path/web3-product-manager) owns directly.

## What should users see while a transaction confirms?

A spinner with no label makes 12 seconds feel like a failure. Split the wait into named states: waiting for your signature, submitted, included in a block, and confirmed. Link the transaction to a block explorer for users who want proof. Let them keep using the rest of the app while one action is pending.

Decide what "done" means for your product. A game can update the screen as soon as a transaction is submitted. A lending app should not show a new borrowing limit until the deposit is confirmed, because a user who acts on a balance that later changes will blame you.

## How do you test web3 UX without spending real money?

Use a testnet. [ethereum.org's networks page](https://ethereum.org/en/developers/docs/networks/) notes that most people get testnet ETH for free from faucets. Pre-fund the participants' wallets yourself, so a moderated session starts at the moment you want to watch and not at a faucet queue. The method is otherwise the same as any [usability test](https://builderscamp.com/guides/other/how-to-run-a-usability-test): real tasks, silent observation and a clear success criterion per task.

One honest limit: testnets are cheaper and emptier than mainnet, so gas feels free and confirmations can feel faster than they will in production. Run a small, funded mainnet check before launch to see the real costs and timings a user will face.

## Is simplifying web3 UX always the right call?

The strongest objection to aggressive simplification is that it can remove the reason the product exists. If an embedded wallet, sponsored gas and a hidden network make the app feel like any web2 service, some users will ask why it needs a blockchain at all, and others will not realise they hold assets they are responsible for. Hiding the chain also hides the risk.

Simplify the mechanics and keep the ownership visible. A user should never need to know what gwei is to complete a first action, and should always be able to find out where their assets live and how to take them elsewhere.

Builders Camp's [Web3 Product Management bootcamp](https://builderscamp.com/bootcamps/web3-pm) lists user experience in a wallet world, covering onboarding, custody, security and reducing friction in key flows, among its published topics. It runs for 2 weeks with 4 live sessions and 8 self-paced microlessons, directed by Andre Albuquerque. For the primary documentation behind each fix above, start with the [web3 product management resources list](https://builderscamp.com/guides/resources/best-web3-product-management-resources).

## Frequently asked questions

### What is the biggest UX challenge in web3?

Wallet onboarding. A new user has to install or create a wallet, protect a seed phrase and fund it before they can do anything on-chain. ethereum.org calls securing seed phrases awkward even for expert users. Every other friction point comes after this one, so fix it first.

### Should a web3 product hide the wallet from users?

Hide the complexity, not the ownership. Embedded wallets tied to an email login and smart contract wallets with recovery options reduce friction, but users should still be able to see which address holds their assets and export it if they leave. Decide how much custody you hold and say so plainly.

### Can a web3 app pay gas fees for its users?

Yes. ethereum.org's account abstraction page lists paying someone else's gas, or having someone else pay yours, as a benefit of smart contract wallets. Sponsoring gas turns a user cost into your acquisition cost, so cap it per user and per action.

### Why do token amounts look so strange in web3 apps?

Contracts store whole-number amounts and a separate decimals value. The EIP-20 token standard gives the example that 8 decimals means dividing the stored amount by 100000000 to get what the user should see. A front end that skips that step shows a meaningless number.

### How should a web3 app handle slow transactions?

Show every state: waiting for the wallet signature, submitted, included in a block, and confirmed. Ethereum produces a slot every 12 seconds, so a single action can take several seconds even when nothing is wrong. Optimistic UI is fine for display, never for balances a user will act on.

### How do you usability-test a web3 product without spending real money?

Run the test on a testnet with test funds from a faucet, which ethereum.org describes as how most people get testnet ETH for free. Pre-fund the test wallets yourself so participants start at the moment you want to observe, not at the faucet.

### Does Builders Camp's Web3 Product Management bootcamp cover wallet UX?

User experience in a wallet world, covering onboarding, custody, security and reducing friction in key flows, is one of the bootcamp's published topics. The bootcamp runs for 2 weeks with 4 live sessions.

## Sources

- [ethereum.org: Account abstraction](https://ethereum.org/en/roadmap/account-abstraction/)
- [ethereum.org: Proof-of-stake](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/)
- [ethereum.org: Gas and fees](https://ethereum.org/en/developers/docs/gas/)
- [EIP-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20)
- [EIP-3085: wallet_addEthereumChain RPC Method](https://eips.ethereum.org/EIPS/eip-3085)
- [ethereum.org: Introduction to smart contracts](https://ethereum.org/en/developers/docs/smart-contracts/)
- [ethereum.org: Networks (testnets and faucets)](https://ethereum.org/en/developers/docs/networks/)
- [ethereum.org: Wallets](https://ethereum.org/en/wallets/)
- [Builders Camp: Web3 Product Management bootcamp](https://builderscamp.com/bootcamps/web3-pm)

## How this guide was made

Researched from Builders Camp's bootcamp, track and masterclass material and the sources listed on this page, drafted with AI, and fact-checked against every source cited.