The most brutalist and efficient library by Sidebay Studio

The use of cutting-edge materials and manufacturing processes in the design and production of Elements_Efi has resulted in a product that is both durable and sustainable, reducing the environmental impact of its use.

A Webflow library infused with the brutalist way.

Launch your portfolio, agency, startup faster than ever

Just drag, drop and make your first MRR faster

From zero poker knowledge to a full multiplayer game.

I was handed a brief: build a multiplayer poker game from scratch, fast. No existing components, no design precedent at the company, and I had never played poker in my life. This is how I figured it out.

Game Design

Multiplayer UX

Motion Design

Edge Case Mapping

Crypto/Gaming

0->1 Product

TIMELINE

April 2025 - July 2025

TEAM

Engineers
Me as designer

TOOLS

Figma

the twist

My first move was to become a player, not a designer.

I wasn’t a poker player. My first step was learning the game deeply: how players think, how money flows, and how competitors structured engagement. Approaching poker with a beginner’s mindset let me strip away unnecessary complexity and rebuild the game into something intuitive, fair, and engaging for both crypto-first users and casual players.

research & insights

I couldn't design what I didn't understand. So I went and learned it.

To bridge my knowledge gap, I conducted:
1. Competitor Audits – Played on platforms like Zynga and PokerNow, mapping flows from lobby → buy-in → gameplay → results.
2. User Interviews – Teammates (poker players + crypto users) became my test group. I asked questions like: What breaks your trust? What makes you choose one platform over another?

Insights:
• Simplicity wins under pressure. When money is on the line, players don't want to think about the UI.
• Animation isn't decoration. It's how players understand what just happened.
• Trust is fragile in crypto. A confusing withdrawal flow loses players permanently, not temporarily.

Competitor Research

The Goals

First, I needed to define what success looked like: for players, for engineers, and for the business. Poker was being built as a retention driver, so every decision needed to balance clarity, trust, and engagement.

01 clarity & onboarding

Make the game intuitive for new players without slowing down experienced ones.

02 consistency & trust

Maintain visual and interaction consistency to build trust in a real-money environment.

03 feasibility

Ensure easy implementation across game states for engineers.

04 interaction design

Use motion and micro-interactions to reinforce game states, timing & player decisions.

mapping the game

Before designing the table, I had to understand what happened on it.

Poker has more states than almost any other game. Pre-flop, flop, turn, river, showdown, and within each of those, a player could be active, waiting, all-in, spectating, or disconnected. I wireframed every stage before touching visual design because I genuinely needed to understand the full state map before I could make a single layout decision.

The harder problem was mobile. The table needs to show six seats, a pot, community cards, your hand, a timer, and action buttons, all at the same time, on a screen the size of your hand. Every pixel was a tradeoff between information and clarity.

Early wireframes mapping poker flow and table layout

the full state map

Mapped every state, edge & transition before a single screen went to dev.

First detailed iteration of the end-to-end gameplay flow

decisions that mattered

At a poker table, every detail is a decision. Here's how I made mine.

To understand this, I observed how experienced players approached the game eg. what buttons they reached for first, how they read timers, and what slowed them down. Using those insights, I iterated on key components and interactions. Here are a few examples:

REFINING PLAYER AVATArs

What should players see first under time pressure?

The player avatar had to pack seat position, chips, blinds, hand strength, and timers in one glanceable element. Initial feedback revealed timers weren’t visible enough → I iterated multiple approaches before finding the right balance between visibility and feasibility.

Iterating on the player timer

Final player avatar designs and components

ANIMATIONs & prototypes

Poker isn't just decisions. It's also anticipation. Animation is how you design that.

‍Since this was my first time designing a full game, I had to learn not only the rules of poker but also how animation could shape the experience. Early on, I started observing what made other poker games exciting, from the way cards flip onto the table to how chips slide toward the winner. I realized these micro-moments weren’t just visual polish; they were what gave players a sense of fairness, anticipation, and fun.

animating user actions

Animating player actions for clarity

Fold: Cards slide away and the avatar fades, making it instantly clear the player is out without needing labels.
All In: Chips shoot to the pot and the bold “All In” label stands out, to signal high stakes

User goes all in

User Folds

COMMUNITY CARDS REVEAL

Mimicking real-life card play

Poker is as much about anticipation as it is about decisions. To capture that feeling, I experimented with animations that revealed community cards one by one, just like a live dealer would.

Final player avatar designs and components

SHOWDOWN & ROUND RESET

How do we make resets feel fair, fast and natural?

Showdowns are high-stakes moments. I designed micro-animations that make the outcome instantly clear - chips smoothly move to the winner to provide immediate feedback. For the round reset, I thought carefully about the sequencing of interactions:
‍
• Dealer label shifts after each round
• Chip movements and direction
• Pacing of card distribution

The goal of these micro-animations were to mirror real-life poker flow with clarity and speed and keep the rhythm of the game engaging, round after round.

edge case designs

In a real-money game, edge cases are the whole game.

Poker is a game of exceptions: timers expiring, players disconnecting, or chips running out mid-hand. I worked closely with engineers and players to stress-test flows against these edge cases, making sure gameplay stayed fair and functional under pressure. This not only improved usability but also reduced the risk of costly rework late in development.

Designing clarity for rare but critical edge case flows

Hand-off

If an engineer has to ask me what happens here, I haven't done my job.

After animating and prototyping key flows and edge cases, I consolidated the designs into a detailed, structured handoff. My goal was to ensure engineers could build quickly without ambiguity. I organized flows and edge cases, anticipated dev questions, and designed a poker lobby that balanced simplicity for implementation with the clarity players needed (buy-ins, seating, waitlists).

End-to-end flow with edge cases and lobby design

testing assumptions & mvp prioritization

Players needed to trust the game before they needed to track their stats.

Being at an early-stage startup, I had to prioritize what was essential for an MVP. I focused on what players needed most to start playing and trusting the product, while advanced features like stats and history were pushed to Milestone 2. To guide these tradeoffs, I asked players directly: What do you actually need during play? What feels helpful vs. distracting?

After finalizing the MVP, I designed additional features for Milestone 2, things that would enhance players' experiences even further. Example features: table info, hand recap stats, and waitlists

End-to-end flow with edge cases and lobby design

what i learned

Not knowing the domain can be an advantage. Going in without poker knowledge forced me to question everything. Why does this button need to be here? What does "the flop" actually mean for the UI? That beginner's mindset stripped away assumptions and led to cleaner decisions early on. But there's a point where you need to stop questioning the rules and start designing within them.

Edge cases are where the real design happens. What actually took time and what actually matters to players is what happens when someone disconnects mid-hand, runs out of chips, or joins a full table. Those states are rare but they're high stakes. Getting them wrong destroys trust instantly. I spent as much time on edge cases as I did on core flows, and I'd do it the same way again.

Animation is a design decision. I used to think of motion as polish you add at the end. This project changed that. The card reveal, the chip movement toward the winner, the fold animation. These aren't decorative. Motion carries information in a game in a way that static UI simply can't.

Designing for real money changes everything. In a crypto game, trust isn't a nice-to-have. A confusing withdrawal flow, an unclear balance state, an error message with no next step. Any of these can be the last thing a player sees before they leave and don't come back. That context made every decision feel more considered. I think it made the work better.