The only wallet app you need



June 2023 on iOS and Android


  • +8% increase in revenue and MAU

  • Created consistency between platforms via component libraries

  • Reduced load speeds to under 1s (down from 9s)


  • 1 Product Designer (myself)

  • 1 Product Manager

  • 6 front-end engineers

    • 3 on iOS

    • 3 on Android

  • 2 back-end engineers

Description is a crypto wallet and exchange with over 80 million wallets and 40 million verified users. started out as a Bitcoin block explorer in 2011. Since then, we’ve introduced our Wallet, Exchange, and a fiat on-ramp for other wallets called Pay.

Superapp came out of a need for clarity and better information architecture. Our goal as a company was to onboard the next 100M users to crypto. Unfortunately, we used uncommon terminology, combined custodial and non-custodial wallets/features, and left the decision making up to users without giving them the information they need to make a good decision.

How do we teach users the difference between custodial and non-custodial wallets and features?

Explaining the difference seems simple when you know the minutiae, but explaining it in an app is easier said than done. Custodial and non-custodial wallets have overlapping and differing features, varying levels of access to crypto, and even regulations in different regions.

So how do we show the difference to new users, while emulating the experience crypto experts are familiar with?

Use anchoring methods

We learned early on that most users don’t, won’t, or can’t do the math in their head about the value of the crypto they hold. Originally, our wallet would just show an amount like 0.09432 BTC. Eventually, we moved to a pattern showing a byline below the crypto amount in the user’s display currency (e.g. $112.89).

I also learned in conversations with family, friends, and people I met at networking events that using real world examples helped those unfamiliar with the terms understand the difference. Essentially, I would compare custodial wallets to having a bank account and non-custodial wallets to having cash in your wallet or a safe in your house.

Separate the two contexts

The biggest indicator that we had a screwy hierarchy was the number of support tickets for users asking what the difference is and why they can’t buy or sell into one but can in another. I played around with ideas that took inspiration from traditional finance apps, but quickly found that the constraints of other navigational elements in the app made it less scalable. 

Eventually, I landed on a concept that completely revamped the navigation, architecture, and visual design of our app. When the head of design and myself felt good with the concepts, we pitched the idea to the product team and our CEO. They loved the idea and assembled the team to work on it.

Tech debt is a real problem

During planning, we uncovered a number of tech debt issues that needed to be resolved for us to be able to successfully build according to the designs. Our team worked tirelessly for a few months to improve app load times, refactor code that hadn’t been touched in years (aka update from Obj-C to Swift). While our engineering team was paving the way for a quicker app, I went through iterations of every screen to update to the new style and architecture.

Component libraries are worth the time and effort

Since we were starting fresh, we decided to finally codify our design system, albeit new, into our codebases. For this portion of the project, we contracted out the work to an agency and I acted as PM for the project. The iOS and Android component libraries were completed within 2 months, just in time for our team to start building “Superapp”. Since then, we’ve been able to iterate quickly and ship new features and tests quickly. Anecdotally, the first test we launched after we released Superapp, was completed within a 2 week sprint. The same project would have taken 2-3 sprints prior to our component library and tech debt clean up.

Testing our theory

As we got closer to release, senior leadership became wary that a drastic change to the UI and architecture would negatively affect our revenue. Despite having done some initial user interviews and surveys with examples of the new design that trended toward positive reception, we decided to hack together an MVP version and run an A/B test. The test netted out neutral with a marginal positive trend. Since the results showed no negative impact, we got the go ahead to continue.

What did we learn?

In the first 2 months, we saw an 18% increase in revenue generating events. At the end of 2023, it had evened out to an 8% increase in revenue generating events. This project helped us understand the importance of contextualizing features and information, the value of using anchoring methods from traditional finance to help users understand the fundamentals of crypto, and the cost effectiveness of implementing a component library.

© ghanbak — now until forever

© ghanbak — now until forever

© ghanbak — now until forever