Installing and trying an application for the first time is a particularly sensitive moment in the usage life cycle. We form a mental model of the features and experience, and how well they address our needs. It can be a make-or-break moment. As designers, our goal is to gently guide users through this initial setup to the point where they are comfortable using the application in the future.
Overall, onboarding typically involves:
- Discovery, download and launch
- Wallet creation and backup, or wallet recovery
- Depositing or requesting bitcoin
How to approach this user flow #
One of the difficult aspects of designing this experience is that users may start out with very different expectations and needs. Someone brand new to bitcoin may want to explore the application thoroughly before committing to it. Another user may already be comfortable and just wants to quickly share a QR code to receive funds.
We recommend designing a flexible first-use experience that guides users towards best practices (the “happy path”). Whenever possible, options should be available to skip parts individual users may not find relevant or dive deeper and personalize settings. If skipped parts are highly important, the application should remind users about them at a later point.
Some studies suggest that users struggled greatly with technical terminology and feeling as though they had a lack of guidance during wallet setup. By walking users through simple steps that clearly frame the features of self-custodial bitcoin wallets, users will feel well-equipped to navigate and use the wallet confidently.
Users reported that they often felt like they lacked guidance and understanding during wallet setup.
As researched by Eskandari et al
The details of this experience can differ vastly based on your technical architecture and use case. For this reference design, we focus on a non-custodial, lightning-first mobile wallet that uses various lightning services to automate some operations, such as channel management.
Discovery and installation #
Before using an application, a user needs to become aware of it, become interested, and install it. Touch points like a landing page and app store listing should already allow users to generally understand what the experience will be like.
Creating a wallet #
Bitcoin wallets contain the private keys (derived from the recovery phrase) to a user’s bitcoin. Private keys let users access bitcoin associated with those keys. If the user does not have a bitcoin wallet already that they want to restore, it is necessary to create a new one.
Like regular keys on a keychain, private keys can be copied. This makes private key management one of the most important considerations of any bitcoin owner. During onboarding, bitcoin wallet applications should automatically generate the user’s keys locally. This means the keys are generated and stored on the device only, not by the wallet provider.
Bitcoin owners can directly access their funds as long as they have access to their private keys or recovery phrase. You should help your users understand that your team does not have the ability to recover their funds in the event they lose this access. A self-custodial wallet means the user will have to take on greater responsibility to safely protect their recovery phrase so they can always access their funds.
While this may sound daunting to first-time users, these caveats mustn’t be hidden. Doing so may severely compromise their funds’ safety, as their default assumptions and behaviors could potentially mimic how they typically use centralized applications (for example, feeling like it is OK if they forget their account information because they can contact customer support to help them recover it).
Wallet backup #
Regularly backing up wallet and user data in a secure manner is essential for bitcoin applications. For small amounts of funds, encrypted cloud backups are a convenient choice with a good tradeoff between security and convenience.
Frequent backups are important for lightning wallets, as channel states frequently change and need to be updated.
Security setup #
While smartphones typically already require authentication to get past their lock screens, it is appropriate for bitcoin applications to introduce further security measures. For example, a user may only require Touch ID or Face ID to access their device, but then set up a unique PIN to access their wallet and send payments.
PINs can also be used to encrypt backup data, both locally and in cloud storage.
Initial deposit #
New wallets start empty and require funding to become useful. Typically, bitcoin is purchased and sent from an exchange, or from another wallet the user controls. Both on-chain and lightning deposits should be supported. On-chain deposits should be automatically swapped to lightning (note that this is a design decision made for this reference design). To prevent user frustration, swap fees should be explained when creating the deposit request. For more on this, see funding.
Receiving the deposit #
The first deposit can be a sensitive moment, so users should be informed as soon as it is detected. There is a high chance that additional fees had to be paid in order to swap bitcoin to lightning or open a new channel. These should be clearly explained so users don’t assume that high fees are the norm. For more detail, see receiving.
Security reminders #
If funds have been deposited and the user has not set up backup, privacy, and security settings properly, it may be a good time to remind them to do so. This is particularly relevant if large amounts have been deposited, making potential loss more painful for the user.
What’s next #
After the first use, users are typically on their own to use the application as it fits their needs, and everything should be set up appropriately. Features that are typically only relevant at later stages of the usage life cycle may benefit from their own onboarding flows. Key is to present introductory information at the time it becomes relevant to the user.
Ok, now let’s look closer at funding a daily spending wallet.