Designing U•HODL, a user-friendly hardware wallet
The device
I joined U•HODL as Product Designer at a relatively late stage: the industrial design was ready, most internal hardware components had already been chosen and early software prototypes mocked basic interactions.
Unlike its main competitors (Ledger Nano X and Trezor Model T), U•HODL has been designed with the following things in mind:
- Smart jewellery: premium materials rather than cheap plastic, with the screen off it does not even resemble an electronic device;
- Mobile: intended to be used on the go with a companion mobile app rather than a desktop client, one-hand operation;
- Wireless: connects to a smartphone via Bluetooth, charges with Qi, the only “wire” attached to the device is a lanyard;
- Secure: it balances security and ease of use.
The team has done a fantastic job designing a device that looks great and is pleasant to hold in the hand.
Now they needed one “last” thing, a user interface to complement the premium look and feel of the hardware.
The screen
U•HODL has a 0.96" OLED screen similar to the ones you find in modern fitness trackers: 120×180 pixels at 225 ppi with millions of colours.
That’s pretty good for a wearable, except for the pixels are still visible… and look weird.
There’s nothing terrible (Ledger’s Nano X has a monochrome display with large, visible pixels), but aliasing on thin lines became too annoying to be ignored.
To find out what’s going on, I prepared a set of test images with lines, circles, rectangles and pre-rendered text to help us reveal the problems.
The engineering team referred to this process of screen testing as “playing snake” because of visible aliasing artefacts on vertical lines.
Soon enough it became obvious that our display does not have a common sub-pixel pattern, but uses something different.
This has been confirmed by macro photos created with the help of a microscope (magnifying glasses are useless at this level of pixel density).
The display manufacturer’s technical support wasn’t very helpful and suggested us to ignore this “feature”.
Instead, we tried to use the good old subpixel rendering (SPR), a method of image rendering that relies on subpixels rather than whole pixels and thus provides higher virtual resolution.
We hired a graphical engineer to help us with this task and in several iterations he has found a solution that worked fine without introducing additional issues like chromatic aberrations.
The visual difference between the original and “sprred” assets was clear, so we decided to update our image processing pipeline.
Ok, now we had a way of displaying high-quality images on the screen. What did this mean?
- The SPR algorithm is rather complex, it cannot be implemented on the device itself, we must use pre-rendered bitmap assets.
- We can no longer freely position elements on the screen, they must be aligned to a 2px microgrid: no big deal until you forget about it :)
- Asset preparation required an extra step: they have to be processed before packing and the number of unique colours increased as well.
- Fonts…
We almost forgot fonts!
This wasn’t a big deal before, but now texts and labels looked ugly in comparison to new images, we obviously had to do something with it.
When designing for embedded hardware, you usually have three options for displaying text:
- Use Monotype’s embedded font library: flexible, powerful, but closed-source and incapable of sub-pixel rendering.
- Use mcufont: open-source, but rather primitive and dated.
- Create your own font rendering engine.
Designing a font rendering of our own was definitely overkill at this stage, so we relied on the <s>good</s> old mcufont to get the job done. Another month of hard work patching and fighting bugs (baseline, kerning, numerous rendering artefacts) in the main library and font encoder and, hooray, we made it.
Why spend so much time fixing these issues instead of replacing a display itself? Mostly because the market of small displays is rather limited and there’s literally nothing to choose from. And as an early-stage startup, we could not afford a custom display.
Buttons and thumbs
Existing hardware wallets rely on physical buttons or touchscreens for user interactions.
Ledger has 2 physical buttons for all possible actions, including text input: they provide clear tactile feedback, so navigation or even typing can be really fast (remember teenagers using T9?). As a downside, Ledger cannot be used by one hand and with a lighter-sized body there are clear ergonomic issues: your hands will literally hurt after using it for a while.
Trezor Model T lives in a completely different paradigm, it uses a touchscreen for all kinds of interactions and the screen is large enough to fit a numpad:
U•HODL has a touchscreen and no physical buttons, so designing interactions for it shouldn’t be too hard, right? Wrong!
What would any designer try to do given a task to create a touchscreen-based UI? Place buttons. Lots of them.
It’s easy to forget about actual experience sitting in front of a 27" display…
No wonder the early UI mockups I’ve found featured on-screen buttons.
Well, why not?
Mainly because there’s literally no room for them. Nielsen Norman Group suggests that touch areas should be at least 1 cm×1 cm while all of our screen space was the size of a thumbnail. Even if we remove all other on-screen elements, there’s only room for two vertical buttons with no safe space in between.
The only remaining control was a fingerprint scanner. Unfortunately, using it for Android-like navigation gestures is impractical: the sensor is very resource-hungry and U•HODL’s battery capacity is significantly smaller than one of the smartphones. The good news is that the scanner has an activation ring that could be used as a simple toggle button.
Now we’re getting somewhere…
After receiving a real device I’ve found a few things:
- U•HODL will naturally fit your hand in a portrait mode, landscape placement doesn’t feel natural (confirmed by numerous observations).
- The screen can only have a single button on it.
- Swipe gestures worked surprisingly well.
Time to make the magic happen…
Designing interactions
After a number of experiments with software prototypes I ended up with the following interaction vocabulary:
- Screen Tap: selection
- Tap and Hold: confirmation
- Swipe ← → for general navigation
- Swipe ↑↓ for changing values and browsing lists
- Fingerprint scan: explicit confirmation, authentication
- Fingerprint ring (the button) Tap: back or a part of other actions
Now we needed to combine these interactions with the UI and ensure everything works as expected…
Modes. A plague of wearables. The number of screens within a given flow could be significant and the user is easily distracted. As a result, you’re often locked in a mode with little or no idea of what to do next.
We’re partially solving this problem by introducing the status bar (on the top) and breadcrumb/paging (on the bottom). The status bar displays the current state/flow name as well as a battery charge (once it falls below 30%) and phone disconnection notification. These indicators are only visible when their state is different from normal, so they do not clutter the screen.
Paging, on the other hand, helps you understand the total number of steps in the flow as well as their type. And being able to navigate back and forth is essential for reducing input errors.
It also prevents confusion on flows like Send, when you naturally have to use both the smartphone and the device simultaneously to confirm or decline a transaction.
This simplified flow of signing (or declining) transactions may look complicated, but the real experience is much more natural, especially if you take security steps into account.
First U•HODL displays “cryptoji” (a signature encoded in a form of 4 symbols) and the name of the “app” (coin name, preferences, etc…), so you could compare them with ones on your mobile app and ensure all further communication is secure.
At this stage, you already know that U•HODL is launching bitcoin transaction confirmation. Swiping left and performing a fingerprint scan is much more convenient than entering PIN and launching the bitcoin “app” manually.
You see the sum, the recipient and may sign or decline the transaction by swiping ← or → and holding the ✅/❌ button.
Swiping navigation is immediately familiar once you start using it. And you always know that positive flows go left to right and negative/destructive options are always on the left.
Using a combination of swipe and Tap and Hold ensures you won’t accidentally lose your assets due to a mistap: we’re designing a device that will be used on the go, so relying on regular taps and screen buttons is not the best idea.
Swipe gestures are not just used for navigation, a ↑ swipe is used for unlocking the device.
On a technical level, it’s a combination of pressing a fingerprint scanner’s “button” and then performing a long swipe before waking up the display.
As a result, we have a natural, easy to perform gesture that cannot be accidentally reproduced, won’t drain the battery or put U•HODL into a lockdown mode while resting in your pocket or being worn as a necklace.
The storage, the speed and the moving pictures
Storage, memory, processing power and battery life are things you should never forget about while designing for wearables.
A wonderful, elegant idea you had just 5 minutes ago is smashed by the engineer explaining to you how it will actually affect the user experience: slow things down, discharge the battery or it’s simply impossible due to hardware limitations.
And a calculator is your best friend: a full-screen, full-colour image requires ~86 KB. Our storage is ~4 MB, so in the ideal world, we could store ~46 full-size images. Not too much, but even less if you recall that you need to store fonts, “apps” firmware and other data.
One of the largest space hogs is our “cryptogy” set, a collection of ~350 images used to display a unique signature and prevent man in the middle attacks. Each of these images, uncompressed, has a size of ~9 KB, resulting in over 3 MB of storage.
This “fingerprint scan” animation has 16 frames, at 96×96 px that’s ~0.5 MB, 1/8 of all available storage.
Why not use the processing power to render everything on the fly?
Good question. But we still have to apply sub-pixel rendering to all assets and the embedded processor is not good at graphics.
We couldn’t even use a PNG-like file format because it’s too resource-hungry for our hardware…
We’re still using a few tricks to reduce image size: reducing the number of unique colours, slicing animations and static frames, applying lightweight lossless compression and so on.
A simple animation sequence like the one above can be compressed to ~1/10 of its original size without much efforts, but as the UI evolves, the number of graphic assets grows significantly.
Building something like this “fingerprint not recognised” animation is a much more complex task because it requires rendering of 8 simultaneous bitmap sequences, each with a slight shift in time. As a result, we may have multiple variations of the same animation using a single set of frames.
Currently most of the images (including animations) need to be packed manually to ensure a balance between visual quality and space. Automated packing and a more efficient asset storage format will save us significant resources in the future.
The mobile app
The hardware wallet stores your private keys and signs transactions, but it’s the app that helps you view and manage your digital assets.
Crypto is far from its maturity and is even further from being user-friendly.
Even with Bitcoin, you cannot just send $20 to John. You need to send 0.002051074 BTC to 1PQCw9DTs7p24jwfegoGyiYfvygEAWh4eU (the address you have likely received by scanning a QR code) and wait half an hour for the transaction to complete. And very often these addresses are disposable, so you’ll have to ask John for another one next time you owe him a few coins. And if you use Ethereum instead of Bitcoin you’ll likely need to figure out what all these bizarre Gas Limit, Gas Price, Ethers and Gweis are.
This doesn’t sound like the future we were promised…
While some of these problems (having human-readable cross-blockchain names) are still looking for a commonly adopted standard, others are mostly results of poor UX design.
After conducting the initial customer development, we found that potential U•HODL users are busy, mobile people having an interest in protecting their digital assets while not necessarily willing to dig into all the technical details of crypto. They’re passing the point when software wallets are not reliable/secure enough and existing hardware solutions are too clunky and complex.
The main flows of the app have been designed within just a few weeks and to speed up further modifications and ease developer hand-off, we started building a comprehensive UI kit with all assets and other UI elements available from a single source.
As the mobile development team lagged behind, I created a small interactive prototype to test my hypotheses about certain interactions.
Sending crypto is often the most annoying scenario, especially if you have ever tried to move assets between your own accounts. And it’s even worse if you just wish to transfer all your Bitcoins from one account to another.
To do this you are usually required to scan the QR code of your own address, then write down your initial balance account, calculate a network fee and enter the remaining number as a “send” value. And good luck doing all this on your single smartphone.
In U•HODLE mobile app you may choose to send all your assets by tapping a single button and change the transaction processing speed (network fee) on the fly without a need to calculate everything manually. Let the computer do the calculations…
As for the recipient’s address, it can be added using any of the following:
- Clipboard: if the text in your clipboard is recognised as a valid address, it is automatically inserted on displaying the Send dialog.
- Typing: if you really are paranoid and have a lot of free time, type the whole address (30+ symbols) manually.
- QR code scan: that’s what everyone does.
- Gallery: the app could access the image gallery and find images with readable QR codes and valid addresses. This is a nontrivial task, but very often these images are clear screenshots.
- Your own account: the app already knows about your accounts, so why not just select them?
All main flows have been successfully tested, so we need to polish the UI (with a flexible UI kit updating the visual design is rather easy), add device configuration and implement the MVP in code.
Further steps
The engineering team is working hard on implementing existing flows on the device while the mobile group makes the app prototype a reality.
We have successfully solved a huge number of user experience issues, tested plausibility of implementing most on-device interactions in the code, but there’s definitely a long road ahead:
We still need to finish the image processing pipeline and an asset storage format, solve numerous graphics engine-related issues, test some complex flows like entering a seed recovery phrase (a real pain of hardware wallets) along with tens of other hypotheses, complete missing flows and much more…
