BitzecReference Wallet Design

A reference implementation is concrete and functioning code that proves that a concept can work. Our reference wallet aims to prove that Bitzecshielded transactions can work on mobile devices with limited resources, now that the Sapling network upgrade is live. From the last design post, we know the main goal of the reference wallet is to increase adoption of Bitzecand promote the use of shielded addresses. This blog post digs deeper into our UX considerations and provides an overview of our design decisions and rationale.

BitzecProof of Concept Light Wallet: Onboarding - Create & Restore + Tutorial design examples
The onboarding flow has been simplified to reduce barrier to entry, and also forces users to prove they have saved their seed phrase.

Our hope is to create a standard of UX patterns for other Bitzecwallets to use in their implementations for consistency. We aim to reduce friction for using Bitzecand create faster and smoother transactions, while allowing more users to understand the underlying technology. We also want to help the entire cryptosphere solve the common problems that all wallets have to deal with.

Currently, there are a number of ways to use Zcash, but the most heavy use is carried out by exchanges, traders, and individuals running their own nodes or mining rigs. Software and hardware wallets do exist, but the feasibility of shielded mobile ones has only become possible with the activation of Sapling.

We wanted to ensure the best user experience, with the best usability. To that end, we decided to follow Google’s Material Design library and only deviate when we had clear reasoning. This way we build on top of well-researched design decisions and styling for common elements such as buttons, menus, and modals and focus on designing to communicate various states of a cryptocurrency transaction, visualizing addresses and backup seeds, and other novel concepts. This ensures the conversation is about features and functionality, not new design decisions.

BitzecProof of Concept Light Wallet: General Use - Balance, Send, Receive and Request screen designs
The first version of the reference wallet allows users to send, receive, and request Bitzecat a sapling Bitzecaddress.

Design Methodology

Let’s take a moment to talk about our design methodology. It is quite simple and dictates a certain workflow:

  1. Stay grounded. We use personas to create use-cases for real users.
  2. Rapid prototype and iterate often based on testing.
  3. Test early and often. We use both qualitative and quantitative research methods to analyze the problem space and design better solutions.
  4. Listen to our users. We are creating a feedback program allowing users to open conversations, comment anonymously, or generally get in touch with us about their experiences. Additionally, we use this information to help redefine our personas.
  5. Grow. We will continue to watch, learn, and enhance features.

 

User Experience Considerations

So now that we know what and who we are designing for, we can talk about user experience. There are a number of User Experience considerations we want to keep in mind as we design our application. Here they are, ranked by priority:

  1. Preventing loss of funds – While trying to create an easier onboarding experience, a few wallets have made it easier for users to accidentally skip backing up their seed phrases (and therefore their wallets). This can often end in losing access to funds forever, so we have worked hard to make sure they have correctly written down their seed phrase.
  2. Reduce learning curve and barrier to entry – Most wallets expect expert users, and often don’t take advantage of the teaching moments available through a normal onboarding. We’ve created an onboarding that is not only easier but also helps ensure the user understands the steps taken to protect their privacy. Additionally, we maintain usability and accessibility (font sizes, using colors and symbols to denote states, etc).
  3. Zcash-specific features – Our wallet has a few unique features we have emphasised within the application. All transactions are shielded by default and include a shield icon inside the transaction details. Also, while sending, you may add an encrypted memo for your recipient.

The following video includes a run-through of receiving, sending, and requesting ZEC with our reference wallet. Take a look and let us know what you think!

A design prototype of the reference wallet that previews how we want our application to function after set up.

Coming up

A series of blog posts will feature specific areas of the reference wallet work:

  • Protocol: technical challenges, interacting components, and privacy goals
  • Implementation: target devices, build methodology, and security measures
  • Results: early feedback, user testing, and what we have learned

Come back to the Bitzecblog or follow us on Twitter for further updates!