BackDesign • 11 min
Design — 3, May, 2026
.png&w=3840&q=75)
The default approach when a Web2 designer enters Web3: apply the patterns you know. Minimize friction. Streamline the flow. Make it feel like a consumer app.
This produces beautiful products that people can't safely use.
Web3 isn't a visual style or a technology layer you design around. It's a fundamentally different operating environment — one where transactions are irreversible, accounts have no recovery mechanism, and the user carries the full consequence of every decision. The UX patterns that maximize conversion in a SaaS signup flow can maximize financial loss in a DeFi product. The friction that feels unnecessary in an e-commerce checkout is load-bearing in a wallet.
This is a practitioner guide to the actual design patterns that work in Web3 — not principles adapted from general UX literature, but specific patterns derived from shipping Web3 products across DeFi protocols, crypto wallets, and NFT platforms.
The failure is not about aesthetics. Web2 UX patterns fail in Web3 because they're optimized for a set of assumptions that Web3 invalidates:
Web2 Assumption | Web3 Reality |
|---|---|
Accounts are recoverable via email/phone | Seed phrases are unrecoverable — there is no "forgot password" |
Transactions can be reversed or disputed | On-chain transactions are permanent — there is no chargeback |
Fees are fixed and shown at checkout | Gas fees are variable, real-time, and expressed in non-intuitive units |
The platform controls user data | Users control their own assets through cryptographic wallets |
Security happens invisibly in the background | Security is explicit, user-controlled, and user-visible |
Mistakes are recoverable | Mistakes can result in permanent, unrecoverable fund loss |
Each of these invalidated assumptions produces a specific failure mode when a Web2 design pattern is applied without modification. A "streamlined" seed phrase flow that reduces copy for readability may reduce the user's understanding of an irreversible decision. A confirmation button styled to minimize friction may enable approvals users don't understand. A progress bar that hides blockchain latency may look like a broken app.
What follows is the correct pattern for each of the high-stakes interaction categories in Web3 products.
Wallet connection is Web3's equivalent of account creation. It is the highest drop-off point in most Web3 onboarding flows — and the highest-leverage design opportunity.
A WalletConnect modal appears immediately on page load or at first action, presenting 12–15 wallet options in alphabetical order, with no explanation of what wallet connection does, what permissions are being granted, or what to do if the user doesn't have a wallet.
Why it fails: Non-crypto-native users (and even many crypto-native users) don't know what connecting a wallet means in terms of permissions. Does it grant spending authority? Does it expose the wallet balance? What exactly is being approved? Without answers to these questions, anxiety prevents connection — especially on new or unfamiliar platforms.
Step | Design Decision | Why |
|---|---|---|
Pre-connection explanation | Before the wallet modal, show a brief plain-language explanation: "Connect your wallet to access the protocol. This doesn't give us access to your funds." | Addresses the primary anxiety before it prevents action |
Wallet selection hierarchy | Surface 2–3 most common wallets first (MetaMask, WalletConnect, Coinbase Wallet), with "more options" below the fold | Reduces decision fatigue; 80%+ of users use one of the top 3 options |
No-wallet path | Include "I don't have a wallet yet" with a guided setup path | Removes the cliff for new-to-Web3 users; critical for growth beyond crypto-native base |
Permission scope | Make explicit what the connection grants: view-only vs. signing authority | Distinguishes "connect to view" from "connect to transact" — most users don't know these are different |
Connected state | Show truncated wallet address + network in persistent header | Confirms connection; allows user to verify correct wallet and network at a glance |
Transaction confirmation is the most consequential UX moment in any Web3 product. It is the point of no return — and the design must ensure the user understands what they're confirming before it becomes irrevocable.
Under-informing: A simple "Confirm" button with minimal information. The user doesn't know what they're confirming, what it costs, what permissions are being granted, or what happens if something goes wrong.
Over-informing: A technical readout of transaction hex data, gas parameters, and smart contract addresses. The user is shown everything and understands nothing.
Element | Design Decision | Example |
|---|---|---|
Action in plain language | Describe what is happening in a single sentence | "You are swapping 100 USDC for approximately 0.031 ETH" |
Fee in fiat equivalent | Show fee in USD (or local currency), not ETH/GWEI | "Network fee: ~$3.20 (varies based on network conditions)" |
Consequence flag for high-risk actions | For irreversible, high-value, or permission-granting transactions: add explicit risk indicator | "This action cannot be undone. Funds will transfer immediately." |
Token approval scope | For contract approvals: show exactly what is being approved, for how much, to which contract | "You are approving [Protocol] to spend up to 1,000 USDC on your behalf" |
Two-step confirmation for high value | For transactions above a threshold: require explicit re-entry or secondary confirmation | Reduces accidental high-value transactions from fat-finger errors |
Risk Level | Characteristics | UX Treatment |
|---|---|---|
Low | Reversible off-chain action, viewing only | Single confirm, minimal friction |
Medium | On-chain transaction, defined amount, known protocol | Plain-language summary + fee display + single confirm |
High | Unlimited token approval, large value, new/unverified protocol | Explicit risk warning + two-step confirmation + "this cannot be undone" copy |
Critical | Seed phrase backup, wallet recovery setup | Forced multi-step ceremony with explicit consequences stated |
Gas fees are the most frequently cited friction point in DeFi UX — and the most preventable. The failure is almost never the fee itself. It is the presentation.
Upfront fee estimation. Show a fee estimate before the user initiates the transaction — ideally on the input screen, not the confirmation screen. A user who sees "estimated fee: ~$4.20" before entering an amount can make an informed decision. A user who sees "fee: 0.0018 ETH" at the confirmation screen is being asked to calculate fiat value in their head at a high-anxiety moment.
Plain-language fee explanation. "Network fee" is better than "gas fee" for non-technical users. "This pays miners to process your transaction on Ethereum" is better still for users new to blockchain. The explanation doesn't need to be lengthy — a tooltip or inline caption is sufficient.
Variability indicator. Gas fees fluctuate in real time. Users who encounter a significantly higher fee than expected feel deceived — even when the product isn't doing anything wrong. A simple "fees are currently higher than usual" banner, with an option to wait or proceed, reduces this abandonment driver.
Fee in transaction context. Show the fee as a percentage of the transaction for small transactions. "$3.50 fee on a $20 swap" communicates something. "$3.50 fee on a $500 swap" communicates something different. Context makes the fee meaningful.
DeFi dashboards contain more data per screen than almost any other product category. Position values, APY rates, health factors, collateralization ratios, claimable rewards, pending transactions, historical performance — the temptation is to display everything.
Most DeFi dashboards are designed for the comprehensive review use case: a user sitting down to evaluate their entire portfolio in depth. The majority of actual DeFi sessions are task-specific: check if a position is at risk, claim rewards, adjust collateral, initiate a new position.
The correct pattern: design for the most common task first, make everything else accessible but not foregrounded.
Pattern | Implementation | Why It Works |
|---|---|---|
Health factor prominence | Show health factor / collateralization ratio in primary position with traffic-light color coding | Users checking for liquidation risk need this at a glance — not buried in position details |
Claimable rewards call-to-action | Surface pending reward value + "Claim" CTA on the primary dashboard, not in a submenu | Reward claiming is a primary action; burying it reduces protocol engagement |
Position value in fiat | Display position value in USD alongside token amounts | Users think in fiat; token-only displays require mental calculation at every session |
Real-time price impact | Show price impact for pending swaps inline, before confirmation | Helps users understand slippage before committing — reduces abandon at confirmation |
Risk indicator at the top | Show consolidated risk summary (any positions near liquidation?) at the top of the dashboard | Most important information for most sessions — liquidation risk is urgent, not secondary |
Transaction status in persistent location | Show pending transaction status in header or persistent sidebar | Users need to know whether a previous transaction cleared without navigating to a separate page |
Anti-Pattern | Why It Fails |
|---|---|
All positions displayed with equal visual weight | Doesn't communicate risk hierarchy — a liquidatable position looks the same as a healthy one |
APY rates as primary metric | APY is important but often less urgent than position health; elevating it obscures risk |
Pagination-heavy transaction history | DeFi users reference history frequently; excessive pagination creates friction on a commonly accessed feature |
Graphs without time-period selector | Showing portfolio performance without context (1D/7D/30D) is noise, not information |
Token symbols without names | Symbols like "stETH" or "rETH" require prior knowledge — plain language names reduce confusion for less-technical users |
NFT platforms have specific UX requirements that differ from both traditional e-commerce and general Web3 products.
Element | Correct Pattern | Common Mistake |
|---|---|---|
Wallet connection | Single wallet connection before the mint page; don't require reconnection mid-mint | Requiring wallet connection mid-transaction creates the appearance of a failed or interrupted process |
Real-time supply counter | Live counter showing remaining supply with clear visual urgency indicator | Static supply number that doesn't update until page refresh |
Gas estimate before mint | Show estimated fee in fiat before the user initiates the mint transaction | Surprise gas fees at confirmation are a primary abandonment driver, especially during high-congestion events |
Transaction status | Post-mint screen with explicit status: "Transaction submitted — confirming on Ethereum (usually 30–60 seconds)" | Redirect to homepage with no status confirmation; users don't know if the mint succeeded |
Reveal countdown (for delayed reveal) | Clear timer with explanation of reveal mechanism | Ambiguous "check back soon" messaging that generates support volume about reveal timing |
NFT platforms operate in a high-scam-density environment. Legitimate platforms that look like scams don't grow — and many legitimate platforms look like scams because they've copied visual patterns from fraudulent projects.
Trust Signal | Placement | Why |
|---|---|---|
Smart contract address (verified) | Collection page, linked to block explorer | Allows sophisticated buyers to verify the contract; signals transparency |
Team doxxing or verified identities | Project page, above the fold | Counters anonymous rug-pull pattern; critical for consumer trust |
Audit badge (if audited) | Mint page + collection page | Security signal for users who understand what audits mean |
Royalty percentage (explicit) | Collection page + marketplace listing | Fee transparency is a trust signal; hiding it signals something to hide |
Community verification | Discord member count + activity | Social proof for active community; shows project is not abandoned pre-mint |
Web3 has more distinct error conditions than almost any other product category — and more of them are consequential. A failed transaction loses a gas fee. A wrong network causes fund routing errors. An expired approval silently fails.
Specificity over generality. "Transaction failed" is not an error message — it's an absence of information. Every error condition in a Web3 product should have a specific cause, a fund status, and a recovery step. The error state taxonomy for a DeFi product should be as deliberately designed as the happy path.
Fund status first. The primary anxiety when a transaction fails is "are my funds at risk?" Answer this question first, before anything else. "Your funds are safe — no transfer was made" vs. "Your transaction submitted but the network returned an error — your gas fee was spent" require completely different UX responses.
Error Condition | Fund Status Copy | Recovery Step |
|---|---|---|
Failed transaction (insufficient gas) | "Your funds were not transferred. Gas fee was spent (~$X)." | "Retry with higher gas limit" + option to set |
Slippage exceeded | "Your funds were not transferred. No fee was charged." | "Increase slippage tolerance or try at a less volatile time" |
Wrong network | "No transaction was submitted." | "Switch to [Network] to continue" with one-tap network switch |
Expired token approval | "No transaction was submitted." | "Re-approve [Token] to proceed" with direct link to approval step |
Wallet disconnected mid-transaction | "If you saw a pending transaction, check your wallet history." | "Reconnect your wallet to check status" |
RPC error / network congestion | "Your transaction may not have submitted." | "Check your wallet history before retrying to avoid duplicate transactions" |
Before launching any Web3 product, run this checklist across the primary user flows:
Wallet connection:
Transaction flows:
Error states:
Dashboard/data display:
The patterns in this guide come from shipping Web3 products — not from adapting general UX principles to a blockchain context. The difference is significant. Designers who have shipped DeFi wallets have seen what happens when a confirmation flow is too streamlined. They know where users abandon gas fee screens, what trust signals work for non-crypto-native users, and which error states generate the most support volume.
At Mara Bureau, Web3 UX is a vertical we've shipped in — DeFi protocols, crypto wallets, NFT platforms, and Web3 analytics tools. We bring the pattern library from real products, not adapted theory.
If you're building a Web3 product and want to review your current UX against these patterns, let's talk →.
Mara Bureau is a UX/UI and product design agency specializing in Web3, DeFi, fintech, SaaS, and AI products.
At our core, we believe in delivering high-quality designs in days, not weeks. This ensures that your project stays on track and progresses smoothly, minimizing delays and maximizing efficiency.
