This guide outlines some principles for designing user-friendly transactions. Our users told us that building effective transaction states was a pain point for them so we've done some design research to try to figure out some do's and don'ts.
Complexity of transactions
There are a number of reasons they're such a pain point for builders:
- Irreversibility: how can you reduce the chance of mistakes?
- Fees (or "Gas"): how and when do you explain fees?
- Technology: how much of the blockchain should you explain?
- Time: how can you communicate progress and explain waits?
- Education: will users without knowledge of transaction want to educate themselves?
If you've struggled with any of these questions, this guide is for you.
Importance of transactions
Transactions are important because they're integral to every dApp. But there are a number of other reasons, rooted in behavioural science, that you may not have thought of.
The halo effect
The "halo effect" is when one trait of a person or thing is used to make an overall judgment of that person or thing. It supports rapid decisions, even if biased ones.1
This means a particularly negative experience will bias your user's perception of any future experience. "Wow, that transaction made no sense, I had no idea what was going on. This site must be really poorly done. Is my money ok? I shouldn't do that again."
The peak-end rule
Cognitive biases change the way that we recall past events. The peak–end rule focuses our memories around the most intense moments of an experience and the way an experience ends.2
This means that an emotionally intense – positive or negative – point of an experience and the end of that experience are most heavily weighted in our memory. A transaction is usually an intense moment at the end of an experience with your dApp. So this might mean a confusing transaction in an otherwise good dApp could lead to users remembering your dApp as bad.
After a series of design explorations we designed a prototype that we iterated on between usability tests. We spoke to blockchain experts as well as those who've rarely or never used dApps before. This gave us the data we needed to make the following recommendations.
Don't rely on wallet UX
For the smoothest and simplest experience, any content related to the transaction should be framed around what the user is trying to achieve. Wallet content isn't specific enough to truly help your users through a transaction because they need to cover so many dApp use cases.
Users lack confidence transacting. It's a combination of new technology, the risk of losing money and transaction irreversibility. Web2 experiences can be faster and more streamlined because errors often have recovery methods. In Web3 a little friction – like a transaction summary – could go a long way in preventing irreversible errors in the first place. Consider what information a user need to avoid common errors, for example:
- their network
- their address
- their balance
- Think about persistent nudges that might set your users up for success – like reiterating to users which network they're on or their current balance.
- Consider introducing some tactical friction to the experience to off-set the chance of frustrating and costly mistakes.
- Help users out. If they're on the wrong network, tell them how to get on the right one. If they don't have enough ETH, help them get more.
- Expect your users to understand the conditions they need to transact successfully.
- Design an experience that doesn't sufficiently protect the user.
Set user expectations
Be sure to communicate an estimated time and transaction fee when summarising the transaction. Your user should be aware of how long it will take and how much it will cost before they confirm the transaction in their wallet. This will prevent transaction fees feeling like hidden fees and allow your user to better plan their next steps.
- Give a time estimate (as specific as you can) – we use: GasStation API
- Be upfront about transaction fees and explain what they're for
- Use vague statements like "This might take a few minutes"
- Expect your user to understand the concept of transaction fees
Just enough feedback
Users only really value certain information when transacting:
- Has it started?
- What's its progress?
- Is it done?
Although it's possible to provide your user with more feedback, this only dilutes the answer to these fundamental questions.
Users also value an indication of progress like a "percentage complete" over UI like a processing spinner. This UI can actually leave some users to question whether their transaction has timed out, increasing the risk of a repeat transaction.
- Only provide the information your user cares about – most users don't stick around to watch their transaction process.
- Use indications of progress like percentages and progress bars
- Provide information just because you can. The more information you provide the more technical the feedback will become.
- Uses content and UI that indicates processing like spinners and "time elapsed"
Design for next steps
Often, a transaction isn't your user's end goal, so your transaction success state shouldn't be a dead end. Think about what your user is trying to ultimately achieve and help them get closer to that goal. Additionally you can use it to encourage the use of other dApps in the ecosystem. As an example, if a transaction generates DAI, you could suggest the user puts that Dai into a DeFi dApp so the user can start to earn interest.
- Design with the user's end goal in mind
- Promote other complementary products that will provide extra value to your user. They might not be aware of it!
- Make your transaction success message a dead end.
- Assume your user knows what to do next.
Try the demo
We made a demo so you can see what this guide looks like in practice.