μWallet is a Bitcoin Cash (BCH) software wallet mockup design for android smartphones, with a target audience of the general public. The purpose of the mockup is to illustrate a way to design more user friendly wallet software by clearly visualizing the concepts needed to progress past the current limitations in wallet design.

Design principles

The design principles used when making software are plentiful and diverse, and for wallet software there is a legacy of well-founded principles that almost all wallets adhere to. The principles listed here are the defining and differentiated principles compared to the average wallet and represent the progress forward, but is in no way any more important than the expected common principles shared in the wallet application space.

Simplicity

Make everything as simple as possible, but not simpler.

When designing any software a recurring problem is featurecreep and misalignment between the target audience and the developer. Due to this, one of the founding design principles of μWallet is to clearly define the scope of the application so that any developer's desire to build feature-parity with other wallets, or to add extra convenience features that aren't stricly needed, can be avoided.

Non-coersive

Backups are good, but not now, ok?

In the cryptocurrency space, it is common to assume that wallet developers always know better than wallet users, and decisions are frequently taken for them, for example by forcing them to make backups or set access codes. This assumption paired with clumsy non-standard ways of doing backups and access codes results in alienation of the consumer base since they feel inadequate. To avoid this, one of the founding principles of μWallet is to never force the user to take any action, but rather guide and help them by explaining to them the benefits and values of taking the action in question.

Discoverability

Wait? I was supposed to long-press there? O.o

When designing applications to be presented in a limited space, and in particular when designing applications without strong planning and early user feedback, it is common to have features that are unexplained and hidden away. These features often work really well for the users that have learned and gotten used to them, but hurt the initial perception of the application and raises the difficulty for new users to find their way.

In a complementary fashion to the simplicity guideline, the concept of discoverability allows μWallet to have a design where the expected use is always visually present and actions that require multiple steps are grouped together and the scope of the action visually shown.

The best competitor so far: Handcash

Handcash is a Bitcoin Cash wallet that pioneered a global alias system called "cashtags" in which users can send value to other people by writing their cashtag names instead of their Bitcoin Cash addresses.

The Handcash wallet is very clean in its user interface and has done a good job with not adding unnecessary features, but falls short on some of the design principles above.

As we can see in the Handcash home screen, a lot of design choices are good but there are a few issues, such as the non-obvious way to receive funds, as well as the empty space under the card that is reserved for future additional cards, but has no indication to the user that this is the case.

If the user is standing in a queue to buy something at a bar or similar, they might be inclined to click that "send" button, which then gives them the following send screen.

In this send screen, when the user is shown the QR code (industry standard), it no longer has access to a way to scan the code, unless it goes back to the home screen. Using a step-by-step wizard also obfuscates the process and there is no progression indicators to let the user know what expectations they should have on the process.

After the user has selected a recipient from the list or by entering an address, it is then shown the value input screen:

On this final screen before a payment is sent, the user can enter how much to send. By making a custom design for the input method, the app overcomes differences in design across devices and operating systems, but loses the advantages of familiarity that standard operating system input methods provide.

This screen also shows a perfect example of a hidden feature, the ability to change between inputting bits/cash and the local currency. There is no visual clues to guide the user to learn how to use this feature, and some users who need it might look for it in the wrong ways, like tapping or double-tapping it, instead of long-pressing on it.

The μWallet work-flow

When you first open the μWallet application the home screen is shown in which the user is presented with the minimal information needed to start using the wallet:

By using reasonably sane defaults and guessing based on context, the wallet will feel great to most users, but some may get sub-optimal results. This is acceptable and the tradeoff that is taken for this wallet design between usability and complexity - instead of asking the user to choose their language, local currency, if they want a new wallet or restore from a backup and so on, we assume most users are non-technical first-timers and act accordingly.

Receiving funds

When the user is ready to receive their first funds they click on receive and is presented with a very basic screen containing all the available options:

The receive screen's purpose is to share the information needed with someone else and at minimum you now either touch the other device (if both are NFC capable) or show the QR code for the other device to scan. You can optionally enter an amount to request, in which case you no longer share your identity, but rather a payment request.

Sending funds

The send screen works the same way, in the sense that it shows you an overview of what needs to be done and allow you to enter the data in the order you prefer, using a variety of methods:

Touching or long-pressing a disabled field should give the user feedback as to why the field is disabled on how to enable it. This touch-to-get-feedback is the one exception to the hidden feature design principle, but it matches so many user expectations and existing behaviours that I feel it is still sane and useful.

Payment codes and contact information

It is worth noting here that the intended way to enter a recepient when you send value, is to select a contact from your address book and let the application do all necessary magic to ensure that the value ends up with that contact. This is not doable with the regular addresses due to the single-use nature, but is instead solved by using the BIP-47 reusable payment codes.

A reusable payment code is like an address in the sense that it is just some technical data that you can store, but it is not single-use. Users will be able to link payment codes to their contacts in their address book and when transactions happen to or from known payment codes the contact information is shown instead of the technically arcane identifiers.

Access restrictions and payment verification

In μWallet it is possible to set a security threshold for verification. If the user sets a threshold, then the send button on the send screen will be replaced with "verify payment" instead, which will take the user to a read-only screen displaying all the payment details to let the user verify that all details are correct before sending.

If the user has configured an access method such as a PIN code, NFC tag or fingerprint, the verify payment additionally requires the user to fullfill that requirement.

Rich history

After having used the wallet for a while, the home screen gets populated with a richer history and some of the unique design features are exposed to the user:

One of the details that most wallets today overlook, is that many users who feel unsafe or unsure about their wallet software will try to manually verify that it works according to their expectations. To do this, they start at the beginning of their transaction history and sum up all parts until they reach the current state, and then compare it with the wallets balance.

To make this behaviour work when using a unit of account different than the stored value the wallet needs to take into consideration the valuation changes that happen over time, so the wallet will add appreciation and depreciation entries that visually show the user why the value has changed.

Reminders

Early on in the design principles we talked about how the application should not force decisions on the user, and how making backups and setting access codes are the most common actions that is forced upon users.

The way this wallet is intended to work is instead to remind the user with rich, explanatory reminders configured to happen at times where they make sense for the first time.

For example, there is no need to ask a user to make a backup before they recieve their first funds, but as soon as there is value to back up, the wallet should make a reminder notification and tell the user that all value stored is stored only on the device and that a backup can help the user restore the funds in case of a broken phone.

Backups however, are really not useful unless they work, and too few wallets take the time to remind the user to verify that they still have functional working backups; so this wallet design will send a reminder to the user 1 week after a new backup and tell the user that it is a good idea to verify that the backup still works.

The users are also reminded about access restrictions once a transaction has been sent, to help guide the user to further secure the access to their funds, without losing convenience or accessibility.

Where do we go from here?

I have shared most of the ideas and details regarding the design that I have done so far, in this article. Anyone who wants to take inspiration from this is welcome to do so.

If anyone is interested in making a full-fledged working wallet out of this design, feel free to contact me on twitter ( https://twitter.com/monsterbitar ) to talk about the difficulties needed to be overcome to create and distribute a working application.