360° roundabout on Beam UX (part 1)

Published in

BEAM Privacy

10 min readJun 3, 2020

TL;DR UX is always our priority and it is a result of the team effort. In this article, I will bring multiple examples of what we did during the last 1.5 years to create a holistically great customer experience across all our products.

We build BEAM altogether: we start the ideation with our design team (with Alexandra Shelenkova and Dasha Tarakanova) move on with the dev and QA teams and of course, listen all along the road to the community ideas and suggestions (honestly, sometimes the discussions can become a bit heated, yet it’s always for the better good as every participant cares a lot about the success of our platform).

Meet and greet

We want everyone to feel at home from the first time they try to google BEAM or to use our products such as wallets, miners, etc.

Our website is a good source of information to start learning what BEAM is. We’ve created a dedicated page for every visitor type:

Regular visitors can read about our wallets’ features before downloading the wallets. And when they have some money, they can always pay with BEAM for all kinds of e-commerce stores.
Miners are equipped with everything necessary to consider BEAM and to start mining.
Traders can easily find where to buy BEAM
Those who aim to take an active part in what happens in BEAM, are invited to join BEAM ambassador program

We also want you to recognize any BEAM-related product from a distance. Therefore, we’ve developed a consistent visual fingerprint for business cards, website, wallets, BEAM explorer, artworks for BEAM-related articles and even for the Telegram stickers :)

Continuous support

Our online presence attends several important aspects:

We keep you updated on everything that happens in the media of your choice: articles, tweets, videos, posts, and many other channels. We are ready to meet you where you feel most comfortable.
We want you to feel confident using BEAM, our support channels for regular users, miners, and developers help people with issues of every sort. I dare to say that we provide world-class customer support FOR FREE: no Zendesk, no case numbers, no bullsh$t emails like “we’ll get back to you within 48 hours” sent from a no-reply address.
Our support team constantly listens and replies to the Telegram channels during the working hours. The representatives are core team members (QA, devs, DevOps, etc), so you’ll get the info from the first hand of those who smell and breathe BEAM even while they sleep. We want your problems solved fast and with competence.
We also maintain a special journal to find the common cases that need to be tackled at the product level.

Easy-to-use wallets

In simple words, we want to gracefully meet the needs of regular, non-geeky users.

In this (longer) section I will bring many concrete examples on how we’ve managed to tailor a friendly face to the monstrous set of technologies that hide under the hood (e.g. Mimblewimble, Lelantus-MW, Atomic Swaps, etc, etc).

Let’s start from reviewing our general UX guidelines:

Every feature should work as seamlessly as possible: whenever a wallet can make a decision automatically, no need to ask the user. From his point of view, it just works.
For every user message, communicate in non-tech terms. No exceptions (well, almost none — and we’re proud of how close we got).
Optimize for the common scenario. Decide the defaults to enable the common needs first. Move the unnecessary switches to advanced sections (or remove them altogether). Don’t provide unnecessary flexibility (indeed, good UX is frequently about what should not be done rather than having a bloated aircraft deck). Advanced scenarios are allowed but not at the expense of the common scenarios.

To the examples now. As a game, try to see which principles revealed themselves for every case :)

Let the wallets talk, not people

To create a Mimblewimble transaction, to send money from one wallet to the other, the wallets need to “talk” directly with each other. Some projects direct users to exchange files or snippets over emails or messengers. Beam Team implemented the short-term storage (called SBBS a.k.a. Secure Bulletin Board System), through which the wallets can securely broadcast messages to each other.

A wallet got to do what a wallet got to do

In the first versions of the wallet, there was an option to mine BEAM. How cool was that! Earn money straight from your wallet. However, we’ve quickly realized that these two functional requirements are relevant to very different user profiles. Moreover, mining BEAM on CPU is proven to be very uncompetitive to GPU mining. Also, the heavy calculations were eating the CPU mercilessly (and also the battery). We’ve taken the miner out and never looked back.

Display % and times on loading, not the number of blocks

When the wallet is synchronizing with the network, the time left is continuously calculated and displayed. The tech team advocated for a more straightforward choice, to display the number of blocks left to download. But “blocks” are insignificant for the end-user (and the wallet load process consists of 3 stages the naive user doesn’t need to care about), therefore, after a few versions, the time approximation algorithm was tuned nicely and the estimated times displayed became fairly accurate.

Isolate the technical parts

Those who understand blockchains know that digital money is represented by so-called UTXO (an abbreviation of “Unspent Transaction Output”, the word “transaction” is abbreviated as “tx” in technical circles). Each UTXO can have a monetary value plus additional parameters (and this is not a place to elaborate on them).

Every user wants to know the balance at each point in time. But this part is tricky: if you have a single UTXO of 10 BEAM and you want to send me only 2, the UTXO needs to split into 2 and 8. 2 will be sent to my wallet and 8 will be returned to you when the transaction is complete. Some technicalities cannot be easily skipped.

We wanted to display UTXO for debugging purposes (especially for the first versions of the wallet), yet we’ve syndicated all the UTXO related information on a single screen that might be removed later with little consequence for the rest of the system.

We still have a remnant of functionality when displaying the change as a part of an outgoing transaction to the sender, but that would be it.

Putting privacy on the spotlight

BEAM is a privacy coin. Meaning that our wallets should project the vibe. The dark theme was a conscious choice (our mobile wallets become even darker at night).

I’ve lived 4 years in Thailand, where people transfer money to each other via banking apps, in seconds (in Israel, my home country, that ease of use is yet about to happen). When I transfer money to someone, I want him to look at my screen to double-check that the transaction details such as name or amount are correct. However, I don’t want him to see my balance.

Mobile wallets got an “eye” button that hides the total amounts of funds, leaving the essential details observable for validation by both sides.

Have a fresh wallet? Try it with some real money!

BEAM faucet (a great community product) can provide wallets with a small amount of real BEAM to play with. Moreover, our mobile wallets are integrated with the faucet, pre-charging the wallet with several taps.

Making seed phrase less painful

Mobile wallets should be used literally on the go. If you’ve met someone on the bus, telling you about BEAM for the first time, you should be able to install the wallet with one hand :) To ease the onboarding, the mobile wallets do not enforce seed phrase verification while the amount kept in the wallet is small enough.

Node connectivity? Never heard of it!

In the past, when the wallet was connecting the peer nodes, it was a lottery: the node might not be the closest geographically, also the node might stop responding and the message to the user was displayed offering him to connect to some other node. How insensitive! Why should he bother at all?

The smarter algorithm was implemented to determine the best node to connect to. The same functionality is used when node disconnects to find the next best node to work with. Fix the problems fast, under the good, and keep the boss calm. You, our dear user are the boss.

For the geeky professionals, we allow tweaking some advanced settings if they want to.

Extendable UI: same screen, greater power!

Till v4.0 (a.k.a. Double Doppler) our wallets were communicating using addresses. “Address” is a friendly and understandable word, nice and simple.

With Atomic Swaps wallets needed to pass more information (such as exchange rate, offer expiration time, currencies to swap with, etc). This information was encoded in what we’ve named “transaction token”. The token looks similar (but is longer than a regular address) and embraces all the relevant information to start the transaction.

Later on, at 4.2 and 5.0, the regular transactions started to carry several data pieces (such as Wallet ID, which is beyond the scope of the article). Therefore, addresses will be replaced with tokens everywhere. Well, almost.

The exception is with never expiring addresses when communicating with exchanges or mining pools. As these are more reluctant to re-implement the infrastructure code, the wallet will still leave an option to create an address instead of a token for the special case.

Keep the user informed without revealing his privacy

To keep the link between “normal” and crypto worlds, the user should always know how many coins he has in the terms, close to his everyday currency.

We’ve implemented decentralized notifications using the same SBBS system mentioned above. The amounts of balance, send, receive can be displayed in both USD or BTC. And, due to the right technology, the wallet IP address is not exposed.

The same mechanism is used when a new wallet version is released.

Complex things should look simple

Atomic Swaps idea sounds simple: you send me BTC to get BEAM in return. But the underlying functionality isn’t that straightforward: two blockchains need to be orchestrated by a state-of-the-art state machine (really, our wallet was reimagined when we’ve introduced that feature) to enable both funds’ transfer securely and without a leak.

However, as always, we wanted to screen the technicalities from the user. Therefore, dynamic statuses were introduced to tell the user what will happen in simple words like timeouts and expected outcomes. Few examples:

The swap is expected to complete in 10 minutes at most

If nobody accepts the order in 10 minutes at most, the offer will be automatically canceled

Swap failed, the money is being released back to your wallet

Here’s the punch: the number of minutes (hours, seconds) is dynamic. We’ve liked the idea so much that we’ve enriched the regular transaction statuses with the same dynamic information:

If the receiver doesn't get online in 10 minutes, the transaction will be canceled.

It is taking longer than usual. In case the transaction could not be completed it will be canceled automatically in 10 minutes.

Bottom line: BEAM wallet users know what to expect at any given moment.

Conclusion

This article was inspired by some of the great ongoing discussions in the Beam Community telegram channel about BEAM Wallets’ usability. I hope that now the reader understands BEAM UX direction way better than before.

In my next article, I’ll describe features that are yet to come to BEAM. So, before you run to our channels to suggest something, please stay tuned for a bit longer and get aligned with what we already know :)