Lesson Learned: There is No Such Thing as Too Much Feedback on Blockchain Transactions
TL;DR: Transactions are the way people interact with dapps. If you want your dapp to be used, make transactions fun, engaging, and easy.
I recently made a custom burner wallet for a house party (not a joke, go read this post if you haven’t yet), and I was blown away by how many people told me it was fun to use (“fun” isn’t a word you hear a lot in blockchain usability). After asking people why it was fun, the answer surprised me. It wasn’t the purposefully-addictive games or the hacker aesthetic, it was the way we handle giving people feedback on their transactions.
I used Blocknative’s Assist.js (full disclosure: my company is paid to work on Assist). It was not a major part of the technical build, nor were notifications really factored into my designs, but boy did they make a whole world of difference to the drunk people who actually used the app.
Why Notify?
In the blockchain world, transactions are a constant. They’re the only way to update the ledger and they’re not going anywhere. That means if you want to leverage the full potential of blockchain technology now or any time in the future, you’re probably going to have a run in with the transaction. Transactions are the way people interact with dapps. If you want your dapp to be used, make transactions fun, engaging, and easy.
Transactions can do any of these things:
- ✅ ️B️e️ confirmed in a reasonable timeframe
- 🔌 Get lost on their way to a node to be broadcast
- ❌ Outright fail
- 🕒 Take seconds, hours or days to be confirmed
- 🙈 Appear confirmed and then appear not confirmed (uncles in Ethereum combined with a cancellation)
This probably isn’t an exhaustive list of the less-than-ideal things that can happen to transactions, and they’re all not mutually exclusive either. In fact, the last three of the above might happen to the same transaction (though you would have to be seriously unlucky).
It’s clear then, that we need to keep end users informed about the state of their transactions (and maybe the state of others’ transactions too) so they can act appropriately.
If a user doesn’t know that their transaction has failed, how will they find out how to retry their action? If a user doesn’t know that their transaction is potentially going to take hours or days to confirm, how do they know that they should try to speed it up? You get the idea. Things fail all the time in traditional apps and it’s no different in Web3. But, without clear language identifying the problem and suggesting a resolution, suddenly failures become much worse.
Similarly but less intuitively, letting users know something is complete allows them to move on to the next thing. This is critical if your plan is to keep them engaged. You don’t want a user to have to think twice about whether their action is complete or not, especially if it requires maths (like a balance check) or if they’re primarily using the wallet to enable something else (like drinking).
But Wait, There’s More
Sure, updating users about the state of their own transactions is a good way to ensure that they manage to successfully complete actions within your application, but it’s not the only reason you might want to notify them. Notifications drive engagement. The burner wallet and the games themselves are not what made the experience engaging. It was the transactions. That’s where the life is. Making the transaction experience richer and more relevant by providing real-time notifications is a game changer when it comes to engagement levels. Want to drive more transactions in your dapp? Use notifications.
Making the transaction experience richer and more relevant by providing real-time notifications is a game changer when it comes to engagement levels.
In the case of our party, we set up notifications to tell people about the status of some of the games within the wallet. When someone became the new leader in a game, everyone else got a notification.
We also set up notifications for people receiving tokens within the app. It was an excellent way to breathe life into the application and show that ‘state updates’ were occurring. All without the necessity of people visiting the page which held the state to be updated. You don’t want your users’ eyes to have to be fixed on their balance to know that it changed. Or to be glued to the screen of the asynchronous game. Instead, give them something which is clear, persists for a few seconds and animates to make it eye-catching. Your users don’t have to stare at iMessage to receive incoming texts, and they shouldn’t have to stare at a single specific screen to be aware of incoming crypto transactions either.
If Blockchains Were Instantaneous, Would I Still Want Notifications?
Yep.
It doesn’t matter how long transactions take, they still have the ability to fail. If you’re not using some kind of consistent method of informing your users about failure cases, you’re not giving your users the attention they deserve.
In our case, we had a dapp which allowed NFTs to be purchased. If two people sent a transaction at the same time, one of them would fail (the correct and desired behaviour). Even on xDAI, with its five second blocktimes, two people submitting the same transaction within the same block is a very real possibility. If it can happen at our party of ~70 people, it can happen at a larger event with an even smaller (or instant) blocktime.
What Else Can I Do With Notifications?
Make them actionable. In the context of a notification about some state change, maybe clicking the notification should take the user to somewhere there is more information about said update. In the context of the animation above, tapping the notification should take you to the referenced game so that you can interact with the new state of the app.
Notifications drive engagement, so allow people to engage with them. There’s no point having a ton of really interesting notifications if users don’t know how to navigate around your application to find all the interesting things which are causing them (unless maybe your notifications are cat facts, in which case they’re evergreen).
Use them as the backbone of your UI feedback. Consistency in UI development is key. If users can expect a notification every time they send funds, they’ll know the process isn’t complete until they get a notification. Same goes for receiving funds. A couple of times in crypto apps I’ve literally had to show my phone to whoever is supposed to be receiving the funds as proof that I’ve sent them; a simple notification for each party negates this terrible, unintuitive experience for good.
In Summary
Give your users an awesome transaction experience — something which is really easy with tools like assist.js — and they’ll make more of them. I can’t stress this enough.
