UX/UI Design Development for DApp
Web3 applications lose to Web2 on UX not because developers are bad — but because a blockchain transaction is fundamentally more complex than an HTTP request. Gas, nonce, finality, signatures, approve flows — the Web2 user knows nothing about this. The UX/UI task in dApp is to hide this complexity where possible and honestly explain where necessary.
Specifics of Web3 Design
Wallet State as the Foundation of Information Architecture
The first thing to design is not "screens" but states. A dApp user is in one of:
- No wallet (new user)
- Wallet installed, not connected
- Connected, not on the right network
- Connected to the right network, don't have required tokens
- Fully ready to work
Each transition between states is a separate UX flow. In most dApps, these transitions are poorly designed: user clicks a button, gets "Wrong network" error, doesn't understand what to do. Correct approach: "Switch to Base" button with network icon should appear preventively before transaction attempt.
In Figma, this is designed via States in Auto Layout components: one button component with variants idle / wrong-network / insufficient-balance / pending / confirming / success / error.
Transaction Flows
Every transaction is at least 3 steps: preparation → signing → waiting. UX should accompany the user through each:
Preparation. Show preview: what will happen, how many tokens in/out, approximate gas. Gas is a particular pain point: users don't understand "0.003 ETH gas fee". Solution — show in USD: "~$4.50 for the transaction". Data from EIP-1559 maxFeePerGas + maxPriorityFeePerGas lets you calculate worst-case cost.
Signing. Wallet dialog opens outside our control. Our task — don't create a visual conflict (our modal on top of wallet). Darken the background, show a light indicator "Waiting for confirmation in wallet".
Waiting. Transaction sent, waiting for confirmations. For good UX — not just a spinner, but a link to Etherscan/Blockscan, approximate wait time (based on current block time and congestion), ability to close the dialog and continue working with a notification on completion.
Approve Flows
ERC-20 requires approve before transferFrom — this is a technical detail that shouldn't break UX. Bad variant: user clicks "Swap" and gets two consecutive wallet confirmations. Good variant:
- Check allowance upfront when loading UI. If sufficient allowance — one transaction.
- If not — explicitly explain the two-step process: "First you need to allow the contract to use your tokens (1/2)".
- Permit2 (Uniswap) lets you combine approve + action into one signature. If protocol supports it — definitely use it.
Design System for Web3
DApp-Specific Components
Standard components (Button, Input, Modal) from any design system. Web3-specific components for Figma library:
AddressDisplay — display wallet address. Always truncated (0x1234...5678), click copies to clipboard, hover shows ENS if resolves. Never show full address in UI.
TokenAmount — token amount with icon. Variants: compact (1.23K), full (1,234.56), usd-equivalent (≈$2,469). Negative amounts in red.
NetworkBadge — network icon + name. Critical for multi-chain dApps. Network colors are standardized: Ethereum #627EEA, Base #0052FF, Arbitrum #12AAFF, Polygon #8247E5.
TransactionStatus — stateful component for transaction lifecycle. Contains status icon (spinner/checkmark/cross), state text, explorer link.
Color Scheme
Dark mode — standard for DeFi/crypto UI. Reasons: long trader sessions, perception of "professional" tool, less fatigue monitoring. Main frameworks: Tailwind CSS with dark: variants, Radix UI Themes (native dark mode).
Accent color — part of brand identity, but there are constraints. Red is reserved for errors and negative values. Green — for success and positive changes. Don't use them as brand accent.
Mobile-First in Web3: Constraints and Solutions
Mobile Safari doesn't support browser extension wallets. WalletConnect v2 via deep link — the only path on mobile. This means: all UI must work with WalletConnect flow (separate app opens for signing).
Touch interface specifics: buttons minimum 44px height, no hover states as primary interaction, keyboard pushes layout up on address input. Address input on mobile is a separate pain: camera scan QR code + ENS resolving as primary input methods, raw address paste as fallback.
Tools and Process
Figma with Figma Variables for design tokens (colors, typography, spacing). Tokens Studio plugin for token sync with CSS/Tailwind. Radix UI or shadcn/ui as foundation component library — avoid reinventing basic accessibility patterns (focus rings, ARIA). Storybook for documenting Web3-specific components.
Process: audit existing dApp (if any) → competitive analysis of 3-5 similar projects → information architecture and state mapping → wireframes of key flows → hi-fi design → component library → handoff to developers.
Development Timeline
UX/UI for one flow (e.g., staking: deposit + withdraw + claim) from wireframes to hi-fi — 3-5 days. Full design system for dApp with 5-10 main flows, mobile version, and component library in Figma — 2-3 weeks.