If you’ve ever used a blockchain application, you may have noticed that something is off. Many break some of the core principles of good user experience design. Forcing users to learn new patterns makes them uncomfortable and ultimately drives some away. We should avoid this unless it’s absolutely necessary. As frontend developers, we have to balance the tension between the nature of blockchain and human-centered design.
Meanwhile, according to a report from statista.com total worldwide venture capital invested in blockchain companies increased from $500 million to $4 billion USD over the last two years. This gives us a huge place to work with. 29% share of companies in the consumer products & manufacturing industry are currently using blockchain. Additionally, over 60% of financial companies are introducing blockchain technology in their systems. Designing the front of a blockchain application we will have to deal with four important problems.
Trust
Just because blockchain technology is built to eliminate the reliance on trust doesn’t mean users will trust the machine or network. Similar problems exist in the self-driving cars industry. Tesla has started publishing safety data comparing its cars using autopilot to its cars not using autopilot and cars in general. Their first report said,
Over the past quarter, we’ve registered one accident or crash-like event for every 3.34 million miles driven in which drivers had the autopilot engaged. For those driving without autopilot, we registered one accident or crash-like event for every 1.92 million miles driven.
Despite this, according to a new report from automotive club AAA, 71% of Americans say that they’re afraid to ride in a self-driving car. What makes us think these people will trust blockchain technology on their banking apps? The design challenge should be to build as much trust through design.
To achieve this we can add to the page blockchain dictionary. In this, we can put every mysterious definition of used expressions. In this part of the app, we can add some instructions on how blockchain and security on our web works. When we use “cryptography” or “ethereum” our user will know what it is. It will prevent misunderstandings of how our application is working. Additionally, the user does not have to know everything about blockchain technology, it’s enough for him to know only things which are used on our platform.
If we inform users on blockchain expressions we should be consistent and natural for user naming. It makes the page clean for every client and lets him feel comfortable with it. Users will know what is happening with his wallets or transactions.
Asynchronous ecosystem
In blockchain technology, in some cases, data from ledger is sending asynchronously to the front app. We do not exactly know at what time we get our data, it could be a few seconds, or hours. Yes, hours. The blockchain itself is effectively single-threaded. Transactions execute one by one and the state of the previous transaction has been altered if it is then referenced by the next transaction.
For example, if we want to assign an incrementing ID to a series of records, we can be confident that ultimately each ID will only be assigned to one record. The problem occurs when we send a transaction. We do not know in advance in what order it will happen relative to other transactions, we don’t know immediately afterward either. The block that just processed may be orphaned and replaced by a block that took transactions in a different order.
In designing our application, we should remember to avoid loaders. When the user starts a new transaction, and on this field will be loading loader for a few minutes, he can be frustrated by the long wait. He can think it is some problem with our platform or start another transaction. We can use states of actions instead of a loader and inform the user with popups why he should wait for a reply.
Lots of keys
The third problem, which we have to deal with is a lot of long and unpleasant keys. Blockchain transactions require public and private keys or long alphanumeric codes. Many blockchain applications use public keys to log in, get your wallet or share your transaction details. Users are accustomed to using a short login and password for those types of situations. We have to change some habits and make him feel safer with the new type of login. View of private or public keys will not help, because they are unappealing visually.
To make the keys seem more pleasant we can show on the platform only a short version of them. If the user wants to see all of it, he can do it with one click of a button. One more problem with the keys is to copy them. When the user will try, there is a huge probability that he does not copy all of it, or copy with some additional space. It can make him irritated. To avoid this, we can create a button for “one-click copy.”
On mobile apps, we can use a quick response code, or QR, which is more familiar to users. We can use it for copy and share our keys.
As frontend developers, we have to deal with lots of keys in our code. There are some great libraries to generate and use keys, for example, CryptoJS, Aes.js or Jsencrypt.
Immutability
Finally, immutability is a core value of blockchain implementation. It means that something cannot change once it’s on a decentralized base. This is the reason why blockchain is a safe technology. Because of that, we can’t give users an “undo” button, for which the user is familiar. Users tend to choose functions without really thinking about the consequences. It’s important for designers to keep this in mind as the blockchain transactions are irreversible.
Once something has been recorded on the decentralized ledger, it can never be altered or deleted, only clarified with a new transaction. It is important to let the user know about it. We should give him a lot of information about why he cannot undo transactions, for example. And we should do it before he accepts this transaction. We can add confirmation steps like an overlay window summarizing the information that’s about to be presented for a new block submission. This process should also be supported by functions that can enable seamless revision and editing. We can also use warnings and popups booster about consequences.
Conclusion
These ideas should help with four main problems to design the front end of blockchain applications. Before starting UI and UX for platform we should really understand how blockchain technology works and why these four problems occur.
Finally, we can deal with four main problems on a frontend application. We have to remember about user trust on our website. Be sure to let user know what is happening. Don’t make user irritated about long time load, warn him. Show all keys in familiar type, and do not let user forget to save passwords.
