Lessons in Blockchain Startups: Noticing the Obvious Problem Can Be the Hardest Part
Exactly one year ago, at ETH Denver 2018, the soon-to-be Blocknative team got hooked on blockchain technology. We learned it was powerful. We knew it was complex. And we started to realize it had the long-term potential to change the very fabric of our society. We also knew the learning curve for new users was <understatement> pretty steep.
We’re builders at heart. And experience has shown us that the best way to really learn something new is to start working with it. So we set out in a relatively straightforward direction: creating an ERC721-based crypto-collectible game that would be both fun to play AND teach people how to navigate the basics of blockchain. At a higher level, we felt this game might be one small step toward accelerating the arrival of the block native generation. And, if we’re being honest, we would’ve happily followed in CryptoKitties’ paw prints (sorry, couldn’t resist).
We quickly learned that playing a trading card game by yourself is a lonely experience, so we hopped on video chats to play the game together. But all too often, we found ourselves narrating what was happening while attempting to conduct multiple on-chain transactions. Which, as it turns out, isn’t all that much fun.
The truth is, the game felt like work. And not just busy work. Frustrating and uncertain work.
When we invited our friends to test it out, many wanted to give up during the onboarding phase — over which we had zero control or input. When we played the game, there was essentially no feedback about transaction progress or failure. It wasn’t clear why sometimes things happened quickly, other times they happened slowly, and sometimes nothing happened at all. Etherscan became both our best friend and our nemesis. If you’re part of a dapp team, this is probably a familiar sensation.
Shown here publicly for the first time: the very rough functional prototype of our first foray into building ERC721 crypto-collectible card games. We built and tested it but never shipped.
Like most people new to the space, we tried to accept this was just the way Ethereum worked — ignoring the obvious experience challenges and pushing our way through. Then, we added a few more interesting features, hoping that new capabilities might make our game more engaging.
Our user testing quickly revealed that the more capabilities we added, the more glaring the usability issues became. While we knew the tech was cool and perhaps even novel, it felt like we were moving in the wrong direction. We were testing with tech-savvy users. If they couldn’t figure it out, who would?
Finally, after ignoring the root issue for too long, we decided to address the elephant in the room: blockchain usability.
We started by building some in-line tools to assist us — and our users — in understanding what was going on behind the scenes. This let us know, in simple terms, the end-to-end lifecycle of all transactions associated with our smart contract.
Also shown publicly for the first time: the first rough functional prototype of what would evolve into Blocknative Assist.
We tested it out and the impact on the user experience was immediate:
Hey, this is super helpful.
Oh... I get it now!
This makes sense. Now I can focus on playing the game.
Our first few prototypes were unsurprisingly quick-and-dirty. But they worked. It was kind of a ‘night and day’ scenario. We finally felt like we were making real headway. This simple feature — designed to guide our users through our prototype game – was proving to be interesting, helpful, and necessary.
Tellingly, as a team we’ve seen this story play out before… and though history doesn’t repeat itself, sometimes it rhymes. In the mid-1990s, teams of savvy Internet developers started building destination websites only to realize that, in order to do so, they first had to invent their own basic infrastructure – like stable web servers or dynamic content management systems. Once started down this path, some of the teams realized that other builders could benefit from using their code. And so they pivoted from building websites to productizing — and later selling — core web infrastructure. While this often proved to be a smart business decision, these teams also helped accelerate innovation and adoption in the Web 1.0 ecosystem.
Similarly, after building our basic assist tooling, we came to realize that blockchain usability could be approached as an infrastructure layer for dapps. We soon decided to wind down development of our original game concept and turn our attention to building well-crafted blockchain usability infrastructure. Ever since, we’ve been laser focused on building robust developer tools that help end-users engage with dapps using simple language, clear direction, and consistent feedback. Hence the name of our first product: Blocknative Assist.
Assist.js is an embeddable widget for dapps builders that translates complex blockchain technology into clear, human terms. Assist.js adds clarity and builds confidence in every user interaction. Because usability drives success, adoption, and ultimately ecosystem growth.
The public beta of Assist.js is now ready for dapp teams to begin experimenting. You can sign up here: https://account.blocknative.com/register
After first getting hands on experience building user-facing dapps with our unreleased game, we’d like to think we’ve taken a step in the right direction with Blocknative Assist. But we’d like to know what you think. So install Assist.js into your dapp today and try it out. Tell us how to make it even better, simpler, more friendly, more usable, and more flexible. Because, the more time we spend on it, the more we believe that we’re all in this usability challenge together.