Six months ago I wrote an article on yours.org outlining some design principles and guidelines for how to make a userfriendly wallet. I wanted to offer feedback and inspire developers to build more userfriendly wallets.
The design looked a bit like this:
While the design I made back then was fully functional, my mindset while making it had been to create a design mockup rather than to build a wallet. It received a lot of positive response but there were still some issues that needed to be worked out.
After I released the wallet design I wanted to build a wallet based on it, but I didn't want to write the cryptographic or security sensitive parts of the code myself, knowing that a misstake on my end could cost somebody their family savings or otherwise damage their lives.
The peer-reviewed widely-used wallet library I needed did not exist back then, but the features are now being integrated in the the libraries used by bitpay.
Revisiting my old design mockups and thinking about how #CashAccounts could be integrated I started from scratch with the same goals as the previous wallet design. Re-reading the feedback on the initial design led to the conclusion that I had chosen a target user base that was too big.
Going from targeting the general public, to targeting specifically the non-technical first-time user, I significantly reduced the requirements of the wallet.
Onboarding user experience
It is important to me that new users can get up and running with minimal effort. I've always disliked the all common onboarding flow where the user is forced to go through some complicated seed word backup process.
Backups are important, but they are not important to the first-time user (at least not before they receive their first significant payment).
So what is important to the first-time non-technical user?
While there are a lot of english speaking users in the world, the people that we're looking to target is the non-technical everyday moms and pops. The people that might not be young, that might not have grown up with the internet readily available and that might live outside the major english countries.
To them, it simply isn't acceptable to use a foreign language. They will feel alienated and insufficient if they have to cope with translating themselves, and if they have to do so while learning something entirely new.
Therefor, the cashual wallet will use the language of the devices operating system when possible, but default to english if there is no available translation. On the very first setup screen, they will have the choice to change langauge if they want to, but the aim is that in 99% of the cases, their preferred choice should already be chosen and used without them making any decision.
By showing the option to control the langauge you empower the user. By using their own language as the default you make the wallet seem familiar and comfortable.
For the time being, virtually every user in the target userbase uses their national currency as their unit of account. The wallet will ask the device operating system for the users locale and preselect the appropiate currency for the user in the same manner it does for language.
The theme allows the user to change to and from night mode. The default is a bright and colorful theme in order to align the experience with a positive and optimistic viewpoint, but the dark theme has some distinct advantages and can be turned on or off as needed.
Traditionally cryptocurrency wallets use technical identifers as payment information. While that works, it is neither humane nor does it give the users a good experience.
Instead, the cashual wallet is focused on strong integration with Cash Accounts, an open-source aliasing scheme that allows users to bind their technical payment information to userfriendly account names, directly on the Bitcoin Cash blockchain.
In order to allow the user the best possible experience they will be asked for a name to use to receive payment on the setup screen, and name registration is automated.
Behind the scenes
Before we move on to the rest of the user interface design I would like to explain a bit in more detail what happens in the background for new users.
When the user have entered a name to use for their Cash Account and the wallet have a reusable address, it contacts a registration service and asks it to register the name with the users payment information. When the registration is complete the wallet verifies the information before using it.
This is done with a 3rd party because a new user has no funds, and cannot complete the on-chain transaction necessary to register the name on their own.
Wallet home and history
Immidiately after the user have created their wallet they are shown an empty home screen. There is an history entry for the wallet creation and a pending entry for account registration.
Until the account registration is completed the user can use their wallet like they normally would, with the exception that they cannot share their account identifier to receive funds and would have to share their technical identifier instead.
After a period of usage, the history on the home screen would start to fill up with transactions and system messages. In the history the user can find how they have received and sent money as well as when they make, verify and sweep backups and change security settings.
When the user has a currency other than the native cryptocurrency as their display currency, the history will also show dynamically calculated entries for appreciation and depreciation of their funds based on the currency displayed. (Though that is not displayed in the screenshot above, and is still a work-in-progress.)
Being able to get a clear view of what happens in your wallet is important to build trust. Having valutation changes listed allows the user to easily do a manual audit of the wallet balance.
When the user takes the initiative to send money they need to tell the wallet:
- Who they want to send money to.
- How much money they want to send.
The send screen has been designed to show the user the full process in a single screen and optimized for the intended use case: sending money to a cash account.
For a new user, this means selecting the recipient field and typing in a cash account identifier, after which the wallet will look up the account and display the account identicon as confirmation of proper entry.
The user then enter how much money to send and once a valid recipient and amount has been entered the send payment button becomes available.
In order to be backwards compatible, the wallet also allows the user to fall back on technical identifiers, either by pasting an address into the recipient field or by tapping the scan icon in the header to interact with a QR code or NFC device.
When the user have sent money to a cashaccount it is available in the contact history for convenient entry.
Sometimes the user might want to send a value measured in a currency other than their display currency. They can easily change the currency used in the send screen by tapping on the current unit in the value entry field.
It is also possible to send all funds in the wallet by tapping the wallet icon in the value entry field, which ensure there will be no dust left in the wallet after sending.
Improvements left to do
The send screen is easy to use and should work really well for the intended use case, but there is still some things that could be improved upon that is planned but not yet implemented in the design.
When the user is trying to send more money than their configured spend lock limit is, the
send paymentshould turn into a
verify paymentscreen which contains a summary of the transaction and the unlock mechanism. This is also the screen that will be shown when the user have scanned a payment request.
The contact list is currently automatic based on the users sending history. This is not ideal as the user might not want all of their repients stored in the list, so favourites and the ability to remove or hide entries has to be added.
The receive screen is somewhat of an odd case. On one hand, it is a must-have feature to easily find out how to receive money, but on the other hand the intended way to receive money is by users entering your cash account identifier.
As such, this screen might not be feature complete and it might change significantly in future iterations, but let's go over what we have right now.
The screen is divided into two sections, the first allows the user to learn how to receive money at any time and the second allows the user to request money now.
To receive money at any time, simply share the account identifier. The intended way is verbally, but there is a share button in the header that lets you share the information in any way your device supports.
To request money right now you enter an optional amount to request, then share the address or payment request encoded in the QR code.
The user interface design for backup management is not yet done. Backups are important and deserve a well thought-out process, top-class usability and peer-reviewed security.
A separate full-length article will be written on this subject later on.
Like all my work in the field the source code is available and anyone is free to use it according to the MIT license. I appreciate all help I can get but don't expect anyone else to do the heavy lifting and for as long as I can afford to I will keep working on crypto related projects.