Product and Usability Challenges of Decentralized Services - Part II

Update #1: Read the 1st part here.

Update #2: Don Tapscott (author of the book "The Blockchain Revolution") created an INSEAD course on Coursera ↗ (Check it out). He actually recommends this post in his Recommended Reading section. Woooot! Thanks, Don.

It’s probably not hot news that the user experience across blockchain-based services and applications is not great, yet.

Part of the reason for this malaise is such that entrepreneurs in the space still mainly build for nerds and themselves. This fact in turn is due to the current technical fundamentals that make it very hard to actually design and build on-par experience for the mainstream.

In this second post I like to further explore the fundamental reasons for the above and the implications for the user experience. Today, I will explore an alternative to the very conventional sign-up pattern used in centralised services. You can find the first part here.

The ongoing challenge herein lies to bring decentralized experiences on par with their centralized counterparts, in terms of overall UX and usability in particular.

• • •

You may wonder why the fuss? In fact, on the surface it looks pretty much the same. Below the surface, it ain’t. In general, the first part gave bit of a technical backdrop to understand the difference between decentralized and centralized web-based software and services. This difference is crucially important to understand. As the name implies, the main difference is: decentralized services work without a central server. Therefore, a lot of logic is moved to the frontend, ie. the browser.

Where's the logic?

Technical differences inspire new approaches. Crypto software designer and developers must adhere to different technical paradigms. On the other hand they, too, must simplify their approaches in order to widen their products’ reach and gain mainstream adoption.

The first part of this article went into explaining the implications of conventional sign-up methods deployed in decentralized services. In this second part we will take a look at a new sign-up pattern for the decentralized future: the so called mnemonic or seed phrase.

We will explore the benefits and potential pitfalls.

New approaches to old problems

Due to its technical differences to centralized services, the crypto industry uses various methods for user or account creation. One method in particular is deployed frequently, called a mnemonic phrase (or seed or passphrase). Waves has deployed such a sign-up, account creation method. Waves uses a 15-word seed or passphrase as the sole means for account creation. Other services, like BitBay’s upcoming web marketplace, will use a 12-word phrase.

Such passphrases will be randomly generated and shown to the user. Here is a typical example:

rubber detect gallery cigar maze program small visual salmon pony cash center update follow effort

Seed phrase for registration: A typical form of blockchain user credentials

Even though this 12-word phrase consists of rather simple words, it’s still not super simple to remember instantly. In fact, the correct order is also incredibly important. In order to assure that you write down and remember your passphrase, the UI usually asks you to repeat it in some way. Waves, in particular, would ask you to drag and drop the 15 words from left to right in the correct order. You will not be able to progress until the order is correct.

This step shall guarantee that you write down the phrase and that you understand the importance of the passphrase as your main key to access the account.

If you want to log into your account you have to enter the passphrase correctly. You may, though, wonder what happens if a word is swapped incidentally: Nothing actually. You won’t be able to log in. In fact, switching a word does not immediately allow you to log in some other account. That would not be secure of course. In fact, it very unlikely that a user can create a valid passphrase for your account by reshuffling the words. This incident (called collision in technical terms) is technically speaking not impossible, but very very unlikely.

This combination of words is pretty unique to that user. It must be, of course.

Once you have generated the mnemonic passphrase, you have all you need to use the service in question. You may now chip in that writing down such a long passphrase is a bore. Well, it’s certainly more work than the top passwords people use like „123456“ or „password“ (Linkedin data breach from a few years ago).

Making the complex simpler

To elevate this, Waves, for example, does suggest to add an account with username and password (let’s call this "Easy Access" account). So, this practically does reintroduce a conventional registration method (albeit not an email address, mind you). The difference is, of course, that the browser does not store that data on any server. It is simply stored in browser storage in encrypted form.

Backup phrase generated by the Waves Platform

The crux to this is such that if you clear the browser cache, any data, the account information included will be deleted. Then again, you have to enter the initial passphrase.

In either case, this does potentially open up usability and security issues:

First, it will not be clear to most users that the "Easy Access" account is not a replacement for the passphrase. It is offered only as a somewhat simpler and more conventional form of login.

Second, a user is not aware that deleting the browser cache will also remove the local (Easy Access) account. Of course, that does not remove access to the service. It may, though, come as a big surprise that she now has to enter the passphrase again.

As long as you have the passphrase, you can remove and recreate local (ie. stored in browser only) "Easy Access" accounts.

Therefore, it does not matter if you do not remember the password for the easy access account. You can remove the account in the UI or clear the cache and then enter the passphrase again.

Now, to nerds and technologists it is apparent that one cannot reset the mnemonic passphrase though. I am sure that to the average user this will not be so apparent at first. Second, the average user may wonder whether the sign-up will later ask for an email address.

Even if asked for an email address, a user will not be able to reset the passphrase. Here, the email would be used for communication with the user only. By not asking for an email address alongside the passphrase generation, I would proclaim that the likeliness is reduced that the average user thinks she could reset the passphrase later on. So that’s good.

On the other hand, some may wonder why do you need a local account if the passphrase is all you need. Well, the nerds are OK with such a passphrase, but will the average user? The nerds may use a password manager (like 1Password) that can copy and paste the long passphrase, no shorter form needed. Will the average user? Probably not.

Making the use of the seed phrase, simpler, by adding a "user account" (stored on browser only)

Will this new method work?

I explored the issues with the "Easy Access" account above. I have not yet seen (enough qualitative) or quantitive data that for such sign-up methods so tell whether they work or not. I would suspect that it’s a far cry from being a truly great method. Furthermore, since the space is still young, new technical method will be invented on which new sign-up paradigms will be conceived.

The great thing about this new method is, though, that it implies that „this service works differently“. Therefore, a user may apply more care when registering for a decentralized service. On the flip side, it does introduces potential issues such as it does not adhere to conventions for account creation that have been learned. In fact, I would actually see this as a big benefit.

Last but not least, you may have noticed that, since no email is used, you can create as many accounts (i.e. addresses or mnemonic passphrases) as you like. You don’t need more email accounts. For example, you can simply use the first passphrase (and account address) to play around with the service. If you don’t happen to transfer any funds to that first address, you can simply forget about its credentials.

Just create a new one.

How the benefits and disadvantages of this new method stand against up against conventional registration methods in comparison (see part one) will explored in an upcoming article.