Hardware constraints

Role

Design lead. Worked with PM to define the problem statement, scope of work, and worked with engineering to define technical constraints. This feature was shipped and is currently live in production.

What is this feature?

At Unchained, we would obsess over the client experience when it comes to their bitcoin vault security. Unchained vaults allow clients to safely secure their bitcoin, with no single points of failure — requiring 2 out of 3 keys to “unlock” their vault, and spend their bitcoin. Unchained always holds 1 key as a backup, in case clients have one of their keys compromised.

When depositing to your vault, a bitcoin address is generated. For the best security, you should always check your address on your “key”, or your hardware device. This ensures that your browser isn’t lying to you.

In addition, before you can verify the address on your device, you must register or “link” the device with your vault, so that the device is aware of the other keys used to secure your vault.

The challenges

USB, browser compatibility, and New Tab 😡

Using hardware keys that are not manufactured or designed by Unchained present some experience challenges. The most popular devices require plugging into your computer via USB, and often have browser compatibility issues.

Also, frustratingly, Trezor devices open a new tab any time you interact with them. Which brings up the question — how do we guide users to follow instructions on-platform, then follow instructions off-platform, and remember to come back on platform to complete further instructions?

Trezor frustratingly sending users off-platform to export public keys.

Asynchronous QR codes and microSD

QR codes and microSD are two other communication protocols between keys and your wallet. Unlike plugging in a USB cable, which can transmit data (like your transaction) in both directions, QR codes and microSD cards require this manual handshake that creates some experience challenges.

For example: scanning a QR code with your hardware key receives the transaction for you to sign, but your computer has no idea if you’ve actually signed on the hardware key or not. The user must manually inform the platform that they have signed, and are ready to pass back the signed transaction back to the computer. Same with microSD!

Exploration and research

Both challenges (USB, microSD) and both features (confirm on device, register vault) required similar solutions, so I clubbed research and exploratory iterations together.

What I was looking to build was a step by step guide for clients to use their device. Often times devices have specific initialization steps that can be confusing to follow, so I wanted to make sure those were clear.

The first round of iterations, I thought the vault registration should happen right as part of the vault creation flow, immediately after creating it.

What I learned after talking to our concierge support team (internal stakeholders) was that there are times when clients may have more than two devices that they need to link, so this fixed step would likely not fit client needs. Additionally, the fact that this step was only required when spending bitcoin, but not for receiving bitcoin, made the concierge team’s feedback even more relevant.

For confirming address on device using USB, I had a few variants that I narrowed down using internal user testing. When I had two, I went to Twitter (to a pulse from the bitcoin community) and incorporated feedback.

Solution

Device registration (Async microSD card communication)

Based on this feedback from the concierge team, I found that it made more sense to cut down onboarding time, send clients right to their vault, and have them register as needed.

Once clients would go to register their device, they would be met with the following steps:

A few things to point out here:

• The client needs to download the Coldcard registration file, move it to their device, and then import.

• Some devices like Coldcard can be intimdating to new users, so showing screens of the device itself was found to be useful in user testing.

• The computer has no idea if the file was actually registered on the device or not. Unfortunately, this is a technical constraint of some bitcoin devices that we have to design around.

Confirm address on device (USB)

As mentioned in the challenges section of this post, using a Trezor device to confirm address opens up a new tab. Highlighting a couple key points of this solution (seen in screenshot below):

• Trezor connect: Once the user opens Trezor Connect and comes back, the modal would step to the next screen, allowing them to verify the address

• Confirm with another device: At the end of the flow, the client is able to confirm with another device (eg. Coldcard)

• “Come back here”: This step instructs users to come back to the platform right after they click the “Export” button on the Trezor tab.