Hiding Blockchain’s Slow UI
As a first time designer in the blockchain space I brought with me a bit of bias and preconditioning to standard UX and UI practices. While the benefits and new opportunities that blockchain provides are well documented, the platform challenges were new to me. In designing the Solidified platform it was necessary to tackle one such problem that feels very similar to the classic problems of an early internet.
The problem
One of the core issues that must always be considered when interacting with the blockchain is transaction speed. Current day users of apps and web services expect speed. Much has been written about modern UX practices for hiding load times and managing users expectations. However, these practices are often intended to hide a few seconds, not the minutes that some transactions take. In addition to the built in challenge of simply working with the ledger, there are also security concerns that occasionally dictate a slower pace of interaction to prevent spamming. For Solidified we deal with these challenges in two primary ways: running transactions in the background and providing tiered feedback.
Background processing
The preferred method of dealing with transaction times is to run them in the background. Hiding the transactions work well when the end of a flow involves passive waiting. One such example in Solidified is posting a new smart contract for review. Posting a contract ends with the user, a developer, waiting for reviewers to look over the contract. This can also act as moment for transactions to take place. In this case, the developer can take the steps to set up the contract and it will automatically post to the public when the background transfer completes.
The secret sauce of when to run transactions in the background are tight. The most important ingredient is that the user shouldn’t have to be present when the result of the transaction triggers. This often shows up when the transaction triggers a result primarily targeted at another user, in our case a reviewer. Other key ingredients are low stakes for errors, the ability to save a draft of work, and the ability to provide notifications when the users transaction is complete. The biggest risk with this method is when a transaction fails you could have betrayed the user’s trust. This is why notifications, drafts and low stakes are important. In those cases where the transaction does fail, the user needs to be notified and not lose any of the work they’ve already done, and have the ability to try the transaction again without impediment.
Tiered feedback
The alternative to background processing is to reduce the number of transactions and provide the maximum available feedback. In Solidified, our commitment to security and trust requires that all parties in an interaction have some stake. Some amount of tokens must be transferred for a submission, contract, bug or dispute. This means that the user must make the transactions before proceeding and therefore the platform needs to support the user through these slower steps.
The most important heuristics to follow in these cases is are ‘Recognition over recall’ and ‘Visibility of system status.’ The user shouldn’t have to guess how large a transaction is necessary to complete their task, give them this information at the time of the action. Likewise, the user shouldn’t have to guess if their transaction is going well. The blockchain will not return a notification so the platform requires an aggressive schedule for pinging the ledger to make sure the user knows as soon as they’ve successfully achieved their goal. Also provide any intermediate feedback the system gets, for example: when a transaction is sent, an anticipation of timing (based on testing) and a clear sign of success when the transaction posts.
While it is sometimes required, we first try to mitigate the need for user-to-platform transactions by having the slower process of the blockchain transfer be done outside our primary flows. We give each user a platform account from which the day-to-day transaction are pulled. This way, the user can make fewer, but larger, transactions and not interrupt her when she has a moment of excitement finding that critical bug! We also integrate with standard tools of the space, like Metamask. These tools allow us to pre-build transactions on the platform UI so we can give the user that critical feedback on what is necessary to proceed. Then, we feed just the critical transaction information to the tool.
Secondary use for background processing
Solidified features another situation that creates slow UI: 3rd party and internal tools. In order to maximize the users experience in our platform, we need to crunch a lot of code. Especially for complex contracts there is a long period running the code through tools. We want to hide these slow processes, but in this case we’re approaching it a different way.
We solve this challenge by running the code at the beginning of a flow and doing a background process, as the user is filling out the necessary form. To execute this properly requires planning for when the transaction will be absolutely necessary, then generating a small amount of friction for the user to slow them down. In Solidified we have the user upload their contract as one of the first steps in our contract submission process. This allows us to do the necessary work to prepare the contract for public posting without showing the user a loading bar.
This technique does not work for transactions. Transactions are an important security barrier to prevent spamming and maintain honesty. In theory, one could request a transaction in the beginning of a flow, but this creates a condition for very high risk. What if the user is interrupted or can’t finish the necessary flow, but the transaction still goes through? We have essentially stolen from this user. Starting a background process at the beginning of a flow may seem very convenient, but it is necessary to always consider the failure states and their consequences.
The reason this flow works for the contract processing is the lack of risk. We’ll know if the upload worked before they start the other steps, and we can interrupt the user at any time if there is an error. The user also loses very little in the event of an error. We can restart her flow easily, without her losing much, if any work. A crypto transaction fails all these checkboxes, therefor a background transfer must always be done at the end of a flow.
Conclusion
Blockchains are getting faster, but as designers we still need to clearly compensate for the pace of the platform compared to other services. Currently, a majority of users on our platform are highly motivated. However, to capture the larger population, it is critical that our DApps meet or exceed the expectation of the larger tech ecosystem. Hopefully these few thoughts help you reduce friction for your users and allow smoother interaction with this new technology.
