By Mehdi HassanWhat makes DeFi UX design hard?
DeFi UX design is hard because the riskiest parts of the experience happen outside your interface. The wallet prompt, the network fee, block confirmation and failures are controlled by the wallet and the chain, not by your app. Your job is to prepare the user for each of those moments so nothing surprises them.
Most dapps are designed by and for crypto natives, who already know what an approval is and why a transaction can sit pending. Everyone else hits a wall of hex strings and jargon at the exact moment they're deciding whether to trust you with money. The rest of this guide goes through each transaction state in order. For how the marketing site hands users over to the app, see our guide to web3 website design.
Moment | What the user doesn't know | What your UI should do |
|---|---|---|
Wallet connect | What they're granting | Say connection is read-only and doesn't move funds |
Token approval | Why there are two transactions | Explain approval vs action, show the amount approved |
Fee estimate | What gas is, what it'll cost | Show the fee in their currency before the wallet opens |
Pending | Whether it worked | Show progress, a block explorer link and what to expect |
Failed | Why, and whether they lost money | Plain reason, whether fees were spent, how to retry |
Success | Where their assets are now | Updated balance, receipt and next action |
How should wallet connect UX work?
Wallet connect UX should make clear that connecting only shares an address, and that nothing moves without a separate signature. That single sentence removes the most common fear new users have.
- Don't ask on page load. Let people browse prices, pools or products before connecting. Ask when they take an action that needs it.
- Show supported wallets clearly, with the most common ones first and a path for mobile users who need a wallet app.
- Handle the wrong network. If the wallet is on another chain, explain it and offer a one-click switch rather than an error.
- Show connected state persistently: a truncated address, the network and a clear disconnect option.
How do you explain token approvals and signatures?
Explain token approvals as giving the contract permission to use a specific amount of a token, separate from the action itself. Users who don't understand approvals either abandon the flow at the second wallet prompt or grant unlimited permissions they'd never knowingly agree to.
Show the two steps upfront
Before the first prompt, show a small stepper: approve the token, then confirm the swap or deposit. Nobody should be surprised by a second transaction.
Default to exact amounts
Where your contracts allow, request approval for the amount needed, with unlimited approval as an informed option for frequent users.
Translate signature requests
If you ask for an off-chain signature, say what it does in plain words before the wallet shows raw data.
Link to revoke
Tell users how to review and revoke approvals later. It signals you're not hiding anything.
Why unlimited approvals are a trust problem
Unlimited approvals save users fees on repeat transactions, which is why many apps default to them. But they leave a standing permission that can be abused if a contract is ever exploited, and security-aware users know it.
The UX fix is to make the trade-off visible: explain that an exact approval is safer and costs a little more over time, and let the user choose. Remember the choice for next time. Hiding the setting reads as the app choosing convenience over the user's safety.
How should a dapp show gas fees?
A dapp should show gas fees as a total cost in the user's own currency before the wallet opens, alongside any protocol fee and expected slippage. Gas is one of the most confusing concepts for new users, and showing it only inside the wallet prompt means they meet it at the worst moment.
- Show one total: amount, protocol fee, estimated network fee and minimum received.
- Label estimates as estimates, and explain that network fees go to the network, not to you.
- Warn when fees are unusually high relative to the transaction, so people don't spend more on gas than they move.
- On layer 2s and cheaper chains, say so: low fees are a selling point worth surfacing.
The same principle runs through all money-movement UX: no surprises at confirmation. Our guide to fintech dashboard design covers fee and confirmation patterns from traditional payments that translate well to crypto.
How do you design pending and failed transaction states?
Design pending and failed transaction states as full screens with their own copy, not as spinners and toasts. This is where many DeFi apps lose trust, because the user has sent money and doesn't know where it is.
Pending
- Show that the transaction was submitted, with a block explorer link.
- Say what's happening and roughly what to expect, without promising a time you can't control.
- Let the user leave and come back. Keep pending transactions in a visible activity list.
- Explain what to do if it seems stuck, such as speeding up or cancelling in the wallet.
Failed
- Translate the reason. "Price moved more than your slippage setting" beats a raw revert message.
- Say whether funds moved and whether the network fee was spent, because that's the user's first worry.
- Offer a specific next step: retry with higher slippage, top up for fees, or switch network.
What does a good crypto dashboard design show?
A good crypto dashboard design shows what the user owns, what it's earning or costing, and what needs their attention, in that order. Positions, health factors and rewards should read at a glance, with risk surfaced before it becomes a liquidation.
- Balances and positions in the user's currency, with token amounts as secondary detail.
- Risk indicators such as health factor or collateral ratio, with plain thresholds and warnings.
- Activity history with pending, completed and failed transactions in one place.
- Variable rates labelled as variable, with history rather than a single headline number.
Dashboards in other industries solve similar problems. The patterns in healthcare dashboard design for urgent alerts, and in HR dashboard design for separating everyday users from admins, both carry over. If your team hears terms like empty state or progressive disclosure from designers, our product design glossary explains them.
Why does DeFi UX suit ongoing design work?
DeFi UX suits ongoing design work because the product changes constantly: new chains, new pools, new wallet standards and new failure modes. A one-off redesign is out of date within months, while a team that watches real users and ships fixes keeps pace.
Pros
- Design and code from one team, so transaction states ship as designed.
- Joining customer calls means fixes come from real confusion, not guesses.
- Fixed monthly price makes budgeting predictable for a protocol or foundation.
Cons
- Not worth it if your product is stable and changes rarely.
- You still need protocol engineers for contracts and indexing; a design retainer doesn't replace them.
- Monthly spend is harder to justify before you have active users.
If you only need a one-time design pass before launch, our guides to app design cost and mobile app design cost cover project pricing instead. For budgets on the marketing site, see crypto website cost.
