Crypto is better because…features…
It’s just another currency…
Primarily, it’s a tech/dev/ops/security challenge…
We can design around it…
Tech savvy crypto users will just get it…
User needs from “crypto” are about crypto features…
It’s just another “value” data point…
It just looks like lots more numbers/digits…
We can always switch in out via stable coins…
We can design around it…


For crypto enthusiasts building products, it’s easy to assume a “build it and they will come” perspective. There can be an assumption that “crypto is better” for everything, and that the benefits of a crypto or token based experience are universally applicable.

As a designer or product owner with an awareness about the advantages of crypto, it’s easy to become blind to our own internal biases after drinking the Kool-Aid, even when evidence challenges our desired outcome. We may underestimate the challenges and discount issues that are obvious to others about something we already believe in because we are committed to making it work. We can be blindsided and overlook the basics of friction and usability issues because we assume that our existing tech-savvy crypto users will just “get it.”

But there’s more to crypto experience than crypto features design.

And the design challenges of the addition of crypto as a currency to a product are more than displaying “just another currency”.


There are many synergies between the worlds of online poker and crypto trading. Designing products and experiences for online poker and crypto trading share many similarities.
Both are data rich, domain specific environments, infused by opportunity and the competitive edge. Both systems involve an element of risk which require users to have a certain level of skill and knowledge to succeed. And both are time pressured environments, increasing the potential for catastrophic user error.
Poker and crypto trading share similar demographics drawn by the appeal of the competitive environment and opportunities to gain an edge through knowledge and strategy.
Balancing the ecosystem for liquidity is crucial for both systems, with diverse user types like fish, sharks, and whales bringing different behaviors and strategies for long-term sustainability.

This is the story of my experience of designing and managing the development of a crypto native poker app and what I learned over the course of the process.

This case study focuses on how “crypto design” and cryptocurrencies can have an impact across a multitude of product development areas.

To read about the full product design process and to view the full visuals, check out the full ZK Poker case study here.



Zk Poker, a crypto native and e-sports inspired desktop poker app was conceived to merge the worlds of poker and crypto. It was a high-risk startup experiment to create a proof-of-concept poker product leveraging the border-less payment possibilities and unification potential that crypto offers, as well as the potential for financial engineering using crypto smart contracts such as yield farming, staking and tokenomics to infuse the poker experience and engage younger generations of players.

Pitched as e-sports friendly whilst remaining true to online poker, it was designed to target and appeal to a younger generation of players by subtle introduction of concepts from e-sports and other gaming types.

To read about the full product design, check out the full ZK Poker case study here.


The ultimate product aim was to provide a poker experience that felt natural as traditional poker but with additional features that captured the essence of the new crypto era, to leverage crossover audience appeal between the two markets. The development goal was to produce an MVP desktop poker client in preparation for a private beta phase. The design mission was to enable users to maintain a USD value in their account without the need to swap currencies or touch USD.


As a founding member of the team, I was responsible for all aspects of the product design of the poker client from the ground up. Initially, I started with one developer and progressed to two junior UX designers and a senior art designer. As a distributed team we collaborated remotely, operating in different time zones and languages. Enabling clear communication on the product design between team members was essential to ensure efficient coordination and speed of progress.

Where we started

Crypto as a functionality enabler

The aim of the project was a proof-of-concept poker product designed to offer users all the benefits of using traditional currency, such as low volatility and convenience, without the need to operate in it.

Ops & Smart Contract Features

Initially, the use case for crypto in the project was driven by a mix of operational considerations and the features enabled by a smart contract system. The premise was to leverage modern financial engineering contracts to provide in-house services such as a BTC/USD hedging service via futures and perpetual contracts. Some of the future features planned were Lock (hedging) BTC/crypto rates, Vault (staking with shared yield/rewards via Jackpot), some coinjoin elements to enhance privacy, reduce costs, and improve security, and eventually, the introduction of our own token.

BTC to start

Starting off, BTC was the preferred option, but the team recognized the flexibility of using other coins and tokens and the potential for the future utility token.

Assumptions about users

= assumptions on challenges

Assumptions on

“The crypto demographic”

We began with the hypothesis that our target players for beta would be experienced crypto users who already had access to BTC and BTC processors necessary for making deposits to our site.

“Techie” Guys

We believed our users would already have an in-depth understanding of BTC values and that it would appear natural to them as just another currency. With their high level of tech savvy and experience, we assumed that they would possess a sophisticated ability to figure out any challenges around crypto as the store of values.

We presumed that they would not have specific needs around crypto as the store of the “values” themselves.

Overestimating and underestimating


By overemphasising our users technical ability, we had reduced crypto to another currency. This separated the value display from UX and led to an assumed that we could design around it like any other currency. We anticipated typical payment/cashier issues around security, complexity, and transparency (transaction fees), but the ultimate challenge would be on dev to create seamless integrations.



Making wild assumptions


Working At Speed

Working in a distributed team in varying locations time schedules, languages and working together for the first time, coherent communication and consensus on the design was crucial. The team urgently needed clear blueprints to start working on the front end, with the goal of getting something to t-shirt size and schedule as quickly as possible.

On/Off Ramps

Viewing it as an on/off ramp and then as system currency we segmented the user flows into two categories: (1) Deposits and withdrawals using BTC only, and (2) in game value display, covering lobby and table values. We turned this into an exercise to capture MVP deposits and withdrawals functionality at speed.

Sketching Momentum

I sketched up basic flows and screens based on traditional wallet flows. Establishing the visual maps enabled us to gain consensus and a common language, providing a rapid overview of the system and a visual reference point for the team. This helped to build trust and momentum at the start, acting as a jump start for the development team.



An agile process

Leaping into the unknown

We had the flexibility to explore different options for value display in the system, including our future utility token. By separating the value display from the user experience and treating BTC as a currency that could be swapped in and out, we were able to develop designs for other screens and move forward in an agile process.

mBTC, uBTC, finney and sats

I had initially used $ as a dummy currency display and began switching out $ to BTC in sketches.
Converting sample buy-ins like 20c/10c led to exploring exploring alternative subunits such as mBTC, uBTC, finney and sats. However, it of course added significant additional cognitive load for users due to the multiple digits and sense of “having to move the comma” (unfamiliarity with more than two decimal places of common fiat currencies) to calculate values.

User control

Exploring alternatives in providing users control and options in settings, such as displaying values in BB (big blind) amounts would reduce margin of error but at a cost to the UX. As players love to play with big and real numbers on the table, psychologically it’s more exciting than flat BB numbers.

display in a $ world

As we progressed, we tried to address the issue, exploring a dual display including USD equivalent. Even so, in contrast to existing mental models of table stakes, the unusual appearance of the BTC numbers and additional digits did not feel natural.

To make a more informed decision, I wanted to cross-reference our findings with wider user experiences before drawing any conclusions.

Learning through experience

Fish, Whales, Sharks & Red Herrings in the crypto design process


The Techie Crypto Demographic – The No Needs Users Bias

In retrospect assuming the crypto audience had a high level of tech experience, and the sophisticated ability to “figure it out” became a red herring in the process and led to a blanketing blindspot when it came to evaluating their needs. This assumption inferred that they did not have any user needs at all.

Numbers vs Values

We assumed that the crypto audience’s deep understanding of BTC values would make it seem like just another currency to them, leading us to believe that displaying BTC values would be just another number display. However, we failed to recognize the distinction between “numbers” and “value expressions.”


We initially assumed that our personas would capture the needs of our crypto users, but they had only captured information about their crypto experience and feature needs.

Biases & Blindspots

As a result, we had a blindspot in assessing our user needs and overlooked the fact that users might have specific needs related to the value of cryptocurrencies as a store of value. We needed better definition of user needs around money values.


But capturing needs in personas wasn’t the only blindspot we had.


Even though we were aware of issues in sketches, the process was misleading as it was too easy to ignore issues in sketch format and they didn’t accurately reflect the subtlety of the issues that would arise in more realistic higher fidelity mockups.


Designing for crypto required a different approach.
The issues involved were more complex and subtle than the usual design process could handle, so we needed to explore them in greater depth.


To address this, I deviated from the normal process and I worked with the team to start early mockups to better appreciate the nuances involved.

Crypto as Visual complexity & Psychological Friction


Visual complexity

As we began to mockup key areas of the UI, the impact of the BTC values on the UX became apparent and we discovered that incorporating BTC values was more challenging than expected. Our initial assumption that BTC could be treated like any other currency and simply replace the $ symbol proved to be inaccurate.
BTC added massively to the visual complexity not just in terms of number of digits, but also impacted the choice of fonts, font styles, kerning, etc.

Visual Clutter & Tight Spaces

The complexity of the values added to the visual clutter, impacting readability and increasing the potential for errors.

Within such an immensely data rich environment, fitting so many digits in such a tight space as the table, whilst retaining proportions within a scaling window was a challenge.
And accommodating the potential variations in number of digits, posed a problem for maintaining a consistent visual hierarchy


The choice of font style became crucial for legibility, with a focus on finding fonts with easy-to-read numerals and natural kerning. We also explored different formatting options for the numbers, such as using commas or spaces as thousands separators, to help distinguish larger numbers.

More to digits than numbers

The mockups helped to uncover not only visual issues but also psychological aspects of the display choices.


Not only were the number of BTC digits hard to read and added cognitive load, but on team review we agreed that they did not feel “appealing”.


We knew that psychologically big numbers are more exciting for players at the table, however, with BTC and BTC denominations, generally the values were many digits long. These unfamiliarities appeared unusual, and cast a sense of uncertainty and dissonance to the experience.

In addition the location of the decimal place was atypical for a currency value and looked “weird”.

Perception of Order

The lack of rounded numbers disrupted the perception of anchoring, order, and quality.

Crypto as USER NEEDS


Our goal was to allow users to play poker using BTC without requiring them to hold dollars.

We analyzed the general needs of players involved in values using formal statements as a starting point.

“As a poker player, I need to grasp information from (multiple) tables) quickly, in a dynamic game, with lots of dynamic changes on the screen,”

This quickly focussed attention in on the table as the core action of the game and the centrepoint for the interaction with numerical values.
Each of the points of values involved, such as stacks, chips, bets, pot, and cards were identified and proportionally structured. And we developed a set of user needs centred around this, including a clean and visually clear display, high readability, and items proportionate to the information hierarchy.

We realized that introducing the display of BTC crypto values conflicted with many of our core user needs and that we needed to explore an alternative to BTC display at the table view.

What we explored was virtual equivalent.

Important lessons

Traversing crypto/fiat worlds

“Virtual Equivalent”

We considered the option of using stablecoins as a “Virtual Approximate Equivalent” while still keeping BTC as the base currency. Our idea was to replace BTC with a virtual stablecoin value (using USDT as the reference in mockups) in the display, while maintaining the balance in BTC. We aimed to follow the existing paradigms used for other currencies and give the user control over the display via settings.

Different points in time

However, when we continued with the segmented player balance display mapping and cross-referenced it with in-game play values, we found that table events at different points in time introduced differences in exchange rates. On table cashout for cash games, the exchange rates not only changed for the chips the player brought to the table, but also for those they won from other players, which could have multiple exchange points at the times they brought the chips to the table. 

Differences in exchange rates at different points in time made this approach impractical.

Temporal factors in CRYPTO/FIAT WORLDS

When dealing with straightforward single point in time price, it’s possible to use fiat and non fiat values interchangeably. However, when temporal aspects are introduced, such as auctions or refunds, the intersection between non-fiat and fiat values can have significant implications on both UX and the business’s bottom line.

As well as rate differences for events at different points in time, other factors caused complications, such as potential for split/dual currency transactions and in cases of significant volatility, speed of overall system rate updates.
When temporal differences are included, it has the potential to detrimentally impact customer experience due to the complexities involved.

This further complicated the UX question of how do we tell the story of the values of the currencies we offer.








Offering BTC as the game play currency would limit the potential audience and result in the platform being too alienating for wider audiences. It would also create confusion for players who may struggle to understand the value of their stakes and resulting in uncertainty and doubt in players minds, leading to hesitation to join the new era.

In order to avoid changing players’ currency perception, we decided to allow them to play in a “USD” value and chose a US stablecoin for the MVP. To give users the option to deposit and hold BTC while playing in USD stablecoin values, we implemented an over-collateralized short-term loan model. Essentially, this allowed for a virtual “conversion” to US stablecoin backed by BTC collateral.

Although later discussions involved USDC, we initially used Tether as currency symbol in designs.

Managing risk in BTC price fluctuations

The system designed mitigates the risk of BTC price fluctuation on the “loan” of table chips for the duration of time the player is at the table, via a liquidation engine using an Over Collateralization Margin (OCM) & Minimum Loan to Collateral Margin (MLCM).

The OCM and MLCM allow for a Maintenance Margin (MM) threshold to be set, which takes into account a % drop in the BTC:USDT price between the time the user starts the loan at the table and the time they exit. If the MM is reached, the player is notified at the table and given the option to exit at that rate or add more funds.

Liquidation engine

The OCM allowed for situation where if BTC price drops sharply between the time the user joins the table and the time they leave, and their BTC balance falls below the MLCM threshold required, the user is exited from the table and the USDT is “liquidated” to repay the loan.


This model eliminated the need for multiple crossovers of exchange rates at different points in time, managed the risk of BTC price fluctuations, and reduced the risk of exploits. This approach also provides a more stable currency experience for the user and a better overall gameplay experience.


Player Perspective


Complexity vs User Needs

The tension between informing vs overloading users

Technically the process for over-collateralized short-term loan model is an advanced concept and involves several steps in the backend. Initially, we started by mapping out each step and we considered explaining each step to the user for transparency.

However, the process of buying into tables is a critical moment for users, especially for our high-value multi-table players who may be repeating the process for several tables simultaneously. At this stage, users prioritize high performance, speed, minimal disruption, and convenience.

Progressive Disclosure

To balance the user’s needs and information, we opted for a model of upfront automation and progressive disclosure. By disclosing secondary features only if the user asks for them, the approach meant that most users could proceed with their tasks without worrying about added complexity, reducing friction and providing a smoother user experience.

Automating for Optimisation

In automating the process in the backend, selecting options on behalf of the user to ensure optimal performance for their needs, it avoided the requirement for the user to learn about the full process in depth in order to access what was optimal for their needs.

As a result, users were provided with enough functionality to handle all of their needs at that time, and we were able to reduce the user experience to one simple screen and click. 

Simplifying complexity for learnability

By shielding users from the complexity of the process, we made the functionality available and accessible in a way that required no prior knowledge of financial engineering, smart contracts or blockchain. 

This approach provided particular benefit for novice users. Deferring advanced and rarely used features to a secondary screen helped ease learnability and avoid mistakes, ultimately improving efficiency of use.

Hiding complexity behind the scenes

From the player perspective, the approach helped players to prioritize their attention, saving them time that they would have spent contemplating features they don’t need. It resulted in a minimized risk and a more stable gameplay experience overall.

The user is presented with a buy-in screen showing a dual balance of their BTC balance and an available USDT value.

On buy-in, the USDT balance displays as a negative value. Subsequent buy-ins reflect the diminishing available USDT value as the available BTC collateral is reduced.

A Seamless Process

When the user finishes playing at the table, on cashout, the loan balance is repaid using the corresponding BTC value, unlocking that portion of the user’s BTC balance. For any remaining USDT balance, the user is provided with the option to credit as BTC or USDT using the corresponding conversion value at that time.

Supporting User Mental Models

The model implemented effectively separated the user’s deposited funds from funds readily “available” for table entry. To reinforce this new mental model, the deposit and balance concepts were changed from traditional schemas.

The player’s balance was updated to “manage bankroll”, supporting a deeper integration into the game world.

The cashier was updated from the old brick and mortar casino paradigm, to incorporate a modern crypto surround and presented as “Wallet”.



ZK Poker – Crypto Native Poker


The work presented here was one aspect of a larger product I led – Zk Poker, a crypto native and e-sports inspired desktop poker app. Check out the ZK Poker case study here