A closer look at a new look for keys

When most people think of design, they’re usually referring to the visual side of elements and illustration. However, on the product design team at Unchained, we’re focused on something more. While we want our users to enjoy their experiences with us and be delighted, for the most part, we don’t want them to notice us. Our purpose at Unchained is to be navigators for our users in all senses—to create designs that are easy to learn and understand, experiences that help them quickly accomplish their goals. And most importantly, we want to build systems built to protect them. 

When I started at Unchained, one of the first projects that I started on was redesigning our keys experience. I soon learned that this would turn out to be one of the most complex, cross-functional and educational projects of my career. Up until this point, we’ve had a relatively basic approach to key components, similar to what is seen elsewhere in the industry. However, as we’ve grown as a company and a design team, the need to break away and create a bespoke user experience in this area became increasingly evident.

Keys are an integral part of our user experience, permeating throughout the entire platform. While keys are a relatively complex concept even for experienced bitcoin users, it’s critical for all users to have a foundational knowledge of them in order to securely store their bitcoin. While practical knowledge around bitcoin is becoming much more accessible, keys can still feel overwhelming to those new to the space.

Here, I’ll outline the process and design decisions we had to make in order to arrive at the new keys experience in Unchained.

Why keys matter at Unchained

Custodial bitcoin platforms can abstract away the complexity of keys because they handle them on the backend for users. However, non-custodial services like Unchained require users to interact with keys both inside and outside of the platform, making them critical and challenging elements of the user’s experience. They’re still a UX problem that hasn’t been solved well, and our goal was to pave the way for a friendly, more intentional component. This means that our users need to be able to identify, quickly learn to use, and understand their keys well enough to have the confidence to successfully secure and trade bitcoin with Unchained. 

Something I learned from my past lives at fintech companies is that users in the financial space are unique in some very specific, important ways. When users are starting out with any new product, they have both logical and emotional responses to the design. And while the stakes are quite low during that honeymoon period for non-financial products, financial products—especially ones involving self-custody—carry more weight. If a user is burned financially due to bad product design, unlike other platforms, they rarely come back. All of this together means that our designs need to be incredibly clear and intuitive, and when a user goes to take a critical action on our platform, they need to feel confident.

Arriving with a fresh perspective

I came into the bitcoin space quite green. I am my own perfect end-user, constantly learning about the technical underpinnings with each new feature that I work on and designing them so they’re more intuitive to new bitcoin users. And that’s an important thing when we want people to be able to use our product who are similarly “fresh” to bitcoin. Since our approach to keys is something that hasn’t been done before, we knew that we would need to be intentional about creating components that took user learning into account, creating space for education through design.

This project was one of the most complex and long-running of my career so far. Over the time I worked on this project, my knowledge grew as the designs evolved. There came a point when I (mostly) understood the concepts behind keys and what we needed to show users, and that was when the designs really evolved. I had literally designed something that I myself had to learn how to use at the same time, and it felt like bitcoin magic. After many revisions, the designs arrived at a place where they were both initially friendly and approachable for newbies while allowing advanced users to interact with a plethora of technical details.

Live footage of my understanding of bitcoin keys after a year working on the project

Cross functional requirements

This project wasn’t just about front-end design, but defining, surfacing and refining a system itself. For example, one of the largest efforts in this project was arriving at shared logical frameworks/terminology for keys across teams. After that, it was a complex cross-functional dance, a push and pull between accurately displaying the information necessary to set up users for success while at the same time not dizzying them with complexity. Different internal teams and stakeholders worked with keys in varying capacities, resulting in differing requests for how keys appeared and functioned.

We narrowed the requirements down to the following: 

• Better represent the system underlying keys by differentiating key types and states
• Improve the overall UX, especially initial user learning
• Create a component set that is adaptable throughout the platform and scalable for future enhancements

Finding the simplest solution that met these varying internal and user requirements was one of the most challenging aspects to this project. Ironically, it can be really complicated to make something really simple. 

Our design approach

When we began looking at the key components themselves, complexity was one of the primary considerations we kept in mind. How do we account for the majority of our end users while creating as simple an experience as possible? Bitcoin users have a huge variance in their knowledge and skill level—much more so than in other industries. We kept in mind two major user groups when working on this project: those with extensive experience in the space, and new users who buy, sell, and hold. Technical understanding is one of the primary barriers to entry for those wanting to self-custody their bitcoin, and something that I kept strongly in mind while designing out the bones of our keys. While some users might want quick access to an xpub and to see a breakdown of every instance of their account key, other users don’t know what an extended public key even is coming into our platform. And that’s where good design comes in. 

During round 20 of this project, we landed on key designs that had the complexity of the starship enterprise’s control panel. Every piece of potentially necessary information was shown on the key in order to cater to all of our user groups. The only problem: they were like looking at the sun—users took in so much information they didn’t understand anything. What had started out as a key component became a dense card, full of key check information, usage status, loan and vault information, and a custom generated identicon. This is when we pivoted to creating a contextual component that was both flexible and drastically simplified. Keys now had a locked structural framework, and we intentionally made the content area flexible enough to only display information relevant to a specific user flow. By putting more control in the hands of our cross-functional engineers and PMs, we created a dramatically simplified user experience. This decision also allows our components to grow with our product, and prevents our team from being a blocker by having to constantly modify component content. 

Part of the complexity behind keys is that they’re used in different ways within our product, and can represent different things. Furthermore, there are different types of keys themselves, an important element that we pivoted to expand in our designs after a stakeholder call a few months in. 

Within the Unchained platform, an “Account Key” is exported from devices and has its own xpub (or extended public key), from which “Wallet Keys” are then derived to be used in wallets for the various products in a user’s account. This relationship is key to a lot of what we do on our platform, and will be something that even experienced bitcoin users would require product education around. We distinguished these two key types in order to more accurately represent the underlying braid model, and became more explicit about different key relationships, representing account keys with what I call the “triple squiggle” and wallet keys with a more obvious “key” icon, since wallet keys are what users would actually be interacting with as such. Similarly, we added in an index number to the bottom right of each key design indicating its relationship to the parent Account Key. 

Keys and our design system

Something worth highlighting is how this project fits into our overall design system and approach to components. We regularly lean on Untitled UI and intentionally create customized components only for high impact areas of our user experience to increase our design/build speed. However, in order to create a product that truly fits user needs we also need to decide where to allocate the resources to design out more specific components that require greater cross-functional resources. To us, it makes a lot more sense to create customized and task-specific components in critical experience areas that have the greatest impact. Keys very much fall in this category, since, as I previously mentioned, our users interact with keys more at Unchained than any other platform on the market.

Conclusion

While our new key designs are a major upgrade from what was previously in the platform, this is only our MVP. Through conversations with users, stakeholders, and in-house experts, we’re already mapping out further iterations that include an even deeper dive into incorporating the braid model, as well as bringing to life some creative rabbit holes that we had to push out until after the first release (which I’m personally very excited about).

A final note: A huge amount of cross-functional effort went into this project, and it highlighted part of why we do what we do so well—we work as a team. Pretty much every department had its hands in this project at some point, and our many stakeholder calls and working sessions allowed us to stress-test, refine and simplify the key components to current iteration. As a designer, this project was a blast to work on. I was able to be my own user for a while, dipping my toes into the complexities of bitcoin for the first time, and distilling what I learned into intuitive solutions. My hope is that the new improvements we’re rolling out, like the key components, help enable anyone who is interested in bitcoin to use our platform. 

If you found this article interesting or you might be interested in working on bitcoin product design, check out our careers page for open design roles.