CyberPoker — Redefining Mobile Poker from the Table Up

It All Started with a Question

When I took on this project, I asked myself one question: what should a truly fun mobile poker game look like?

Competitors each had their own answers. Hi Poker put social first with a casual interface for beginners; Poker X focused on competitive play favored by veterans; Pokerrr made private games more flexible. But these products had one thing in common — they all positioned themselves within a known framework, stacked features on top, and waited for players to come.

What we wanted was to find a position outside the framework.

Build the Foundation First: Understand the Product, Understand the Players

Before getting our hands dirty, we spent time on two things.

First was truly learning to play poker. Learning the rules was quick — the hard part was understanding players' mental models: when they feel tense, when they feel excited, which actions give them that 'rush.' This process made me realize poker's charm isn't in the cards — it's in the uncertainty of waiting.

Second was defining who our players are. We targeted recreational players — not professional players, but those who want to escape daily life and feel some excitement at a virtual table. This decision shaped nearly every subsequent design trade-off: 3D scene choices, character-based design direction, and betting redesign all revolved around two cores: 'immersion' and 'readability.'

Designing 'Fun' as a System

We wanted players to not just play once, but keep coming back.

We drew from Nir Eyal's 'Hooked Model,' breaking the entire game lifecycle into four stages:

How to get people to first notice the game (Trigger), how to get them to actually keep playing after opening it (Action), how to make every round have unexpected surprises (Variable Reward), and how to make them leave their own mark in the game so leaving feels a bit reluctant (Investment).

This framework added a dimension to our feature design — asking not just 'is this feature usable,' but 'what role does this feature play in the entire game journey.'

Development: Making Ideas Concrete

Once we entered development, communication became the biggest challenge.

We weren't just dealing with designers and engineers — there were also 3D artists, game logic developers, and clients. Everyone had slightly different visions of the 'final product.' To align these visions, I chose to communicate using Wireflow + Storyboard — instead of separating wireframes and flowcharts, we drew 'what happens after each player action' as a continuous storyline.

This decision saved enormous back-and-forth time, and allowed the 3D art team to understand the atmosphere and rhythm scenes needed to convey before even seeing actual interfaces.

Development followed Scrum with sprint cycles. After each increment, we immediately tested, gathered feedback, and iterated. This approach meant we didn't have to wait until 'done' to discover problems.

The Hardest Thing to Design Is Often the Smallest Detail

Throughout the project, one design problem consumed the most time: the betting wheel.

Almost all existing mobile poker games use sliders to control bet amounts. But after observing actual player behavior, I found a fundamental problem — when holding a phone with one hand, thumb reach is limited. Sliders easily overshoot, and during hesitation, players slide back and forth, slowing decision pace.

We explored two to three versions, progressively simplifying from information-heavy designs, ultimately landing on a 'segmented selection' interaction logic. From Mockup to Prototype, built in Figma for testers to experience, each round had clear questions and metrics, with evidence-based revisions.

This process made me realize something more clearly: 'simplicity' isn't the starting point of design — it's the destination.

Before Open Beta: Three Rounds of Table Redesign

Simplifying the game interface was another protracted battle.

3D scenes provided rich visual layers, but also brought massive amounts of information that needed controlling. The table had chips, cards, player avatars, timers, action buttons — every element had a reason to exist, but together, the screen said too much.

Before the open beta launch, the table interface went through two to three versions. Each version had testing, issue collection, and data-driven trade-offs. The final version wasn't the 'prettiest' — it was the one that 'showed players the right information at the right time.'

Looking Back on This Journey

CyberPoker wasn't just a project for me — it was a real test. Finding balance between client needs, technical constraints, and user experience while continuously making evidence-based decisions amid uncertainty.

Behind every design decision is a 'why.' Being able to clearly articulate that 'why' is what I believe to be the most core ability of a product designer.

Showroom