In September 2017, I was asked to work on a future iteration of the Coinbase mobile application.
I provided a brief pitch deck to outline my process and design recommendations for the Dashboard & Wallet experiences of the mobile application in an Android environment. It was positively received, though timing did not allow me to present it before starting work with Vineti.
Coinbase currently supports three currencies – Bitcoin, Ethereum, and Litecoin. How would you think about changing the app to support many more currencies?
Cryptocurrencies are a complex topic.
With many unknowns and varying levels of understanding, I began by calling out three high level assumptions to frame the problem. These assumptions were based on my understanding of cryptocurrencies and the role of Coinbase as an unbiased exchange.
- "Currencies" referred (primarily) to additional types of cryptocurrency.
- Adding more currencies was not a change in Coinbase's business model or strategy.
- There was no set number of currencies and all currencies would be treated equally.
Is it just another “tab”?
At the time, Coinbase supported three currencies throughout the application. When a user was in one area of the product (ex. the Dashboard, Buy/Sell), they selected one of the available currencies to take action. Selection was often done using tabs (except in the case of separate currency wallets). Because tabs would not scale as currencies were added, I considered briefly if this was just an interaction/selection problem.
Adding more currencies would mean more data, more choice. It meant the potential for more engagement, and more diversity of users and goals. As the underlying data expanded, it was necessary to consider corresponding changes to experience, expectations, and needs.
Before changing the application, I needed to understand the current experience.
What was the current experience for users? What support did Coinbase currently provide? How did that experience relate to user and company goals? What were the different touch points for currencies? How would having more currencies change the goals or interactions of those touch points? To understand these considerations, I created a map of the Coinbase experience based on analysis of the application, personal experience & user conversations.
Increasing the number of currencies would require a balance between breadth & relevancy of information.
Do the needs & changes vary by persona?
Does it matter if the user is an early adopter with high tolerance for risk and lots of money? Or if they’ve just starting to understand cryptocurrency and have about $10 in Coinbase? Yes - they make decisions in different ways relative to their risk tolerance, assets, knowledge, etc. They also may use different parts of the application more than others and in different ways. Understanding those personas was important and might impact which currencies were added or future features/flows.
But - for the purpose of adding more currency types, it was less important. Adding more currencies would be an expansion of existing actions and would not change the core goals of the current Coinbase application.
The Dashboard provided an overview of currencies and, specifically, information to support buy/sell decisions.
With more currencies, the user would still need access to all of that information, but assistance cutting through the noise to see just what was important to them. Decisions would become more personal.
Dashboard Option #1
Just “Another Tab”
Same information, new interaction. Instead of tabs, the user would select currencies via dropdown. They would also be able to change the base currency as well.
Dashboard Option #2
Portfolio + Currency List
To cut through the noise, I divided the dashboard into two sections: a a dedicated portfolio view and a complete currency list.
This segmented currencies that were already part of the user’s holdings, making an educated guess about data they found most interesting. It would help the user make decisions to buy/sell that were grounded to their current portfolio - while giving them access to a full list of currencies. I also introduced an average cost per unit for faster comparison (for buy/sell decisions).
The Currency List provided basic information about all available currencies. Users could filter and sort the list as desired, and change the base currency as well. Each currency expanded to show the detailed price graph. The list also incorporated the average cost per unit for current holdings.
Wallets held unique currencies, allowing the user to easily spend and receive money. With more currencies, a separate wallet for each currency was not scalable. (Only providing wallets for already purchase currencies would also limit the ability to receive money.)
However, recognizing each currency as a separate entity was still important.
Wallet Option #1
I created an aggregate view for wallets to streamline the experience of getting into wallets. Each currency was still a separate “wallet”. The user could filter their wallets, change base currencies, and see the combined value of their wallets.
Wallet Option #2
At the time, each wallet displayed a list of transactions for the corresponding currency. I aggregated the transactions list, allowing it to be filtered by currency. This eliminated the need to drill down into each wallet and treated “Transactions” as a high level grouping (rather than segmenting by currency type).
Wallet Option #3
I modified the request flow to allow users to set the value of their request, then change the base currency; or change the base currency first. This would give them flexibility to request a variety of currencies using the same mechanism, but also made assumptions about the constraints of a request.
Adding additional currencies would also impact the buy, sell, and payment flows.
Before tackling the buy and sell flow, I wanted to learn more about the future of transactions.Buying and selling are, in some ways, the same thing: exchanging one currency for another. With more currencies, this may become more complex, merge into one “Trade” functionality, and/or include new legal constraints.