Why Your Betslip Is Wrong: UX of a Trading Terminal

This article is part of the Flatstudio × MollyBet case study. It is for designers and product teams in iGaming and fintech, where data-dense UX decides whether users trust a platform with real money. The main article in the series is available here.

A Trader’s Mental Model Defines Data Hierarchy — And Why Confusing It With a Sportsbook Costs Real Money

Most betting platforms are built around one assumption: the user picks a team, enters an amount, and waits. This mental model shapes everything — hierarchy, layout, and flows. For a platform where most users place one bet a week on their favorite league, this makes sense.

MollyBet also has these users. But it also has professional bettors who monitor odds movement across 15 bookmakers at once, split orders when one provider lacks liquidity, and treat a 0.05 line movement as an important signal. These two users share one platform. They do not share the same mental model.

When we started the redesign in March 2023, the real challenge was designing for both without compromise.

One Platform, Two Mental Models

A professional bettor on MollyBet does not “place a bet.” He executes an order. The wording matters because the cognitive pattern is different. He monitors, compares, decides on execution speed, and tracks positions across providers — similar to how a trader manages positions instead of making a one-time purchase.

A casual bettor browses leagues, finds a match, checks the odds, and presses confirm. The interaction is exploratory and linear. One experience is a cockpit, the other is a storefront.

Building one product for both meant separating these journeys at the architectural level, not just visually. The data is the same, but the entry points, information hierarchy, and navigation logic are different.

The wrong solution would be giving users a “simple mode” toggle. The right solution was building the separation into the product structure, so neither user ever feels the platform was designed for someone else.

The Order Book Is Not a Feature

For professional users, the order book is not a secondary screen. It is the product. Dark orders, cashout mechanics, win-loss grids, and tracking positions across providers form the core workflow for serious bettors.

We designed two trading console modes: classic and exchange.

Switching between them is instant on any device.

• The classic mode focuses on bookmaker comparison.
• The exchange mode shows full order depth like a financial trading platform.

Both modes were essential. Removing either one would create a completely different product.

The pinning feature came from a specific problem. Analysts monitoring several live events at the same time kept losing context during long scrolling sessions. Pinning a match or market keeps it visible while the rest of the list updates in real time. A small interaction with a huge impact on focus during stressful sessions.

We made hierarchy decisions based on usage frequency under time pressure — not on what looked logical in a product brief.

15 Bookmakers on One Screen

The real challenge was handling data. Real-time odds from 15+ providers, live events, price history, and order statuses all update simultaneously. The Sonic core handled the performance layer. Our job was managing cognitive load. On desktop, we used a clean grid focused on primary markets, while secondary data stayed accessible without dominating the interface.

On mobile, we introduced:

• smart aggregation,
• tap-to-reveal secondary information,
• and one-hand-friendly vertical navigation.

The mobile My Orders Overview included a dynamic graph with green and red position indicators. It was designed for users who need to understand their exposure instantly during a live session from their phone. It is the difference between a betting app and a financial tool. Recent Orders followed the same principle.

Each order included a complete status chain:

• accepted,
• partially executed,
• routed between providers,
• settled.

Users managing volume across 15 bookmakers inside one account need brokerage-level transaction transparency — not a simple summary saying they “won” or “lost.”

Order history is where trust between the platform and professional users is built. The notification center also received detailed visual differentiation. A maintenance warning looks different from a settled bet notification, which looks different from a system alert. In live betting, a missed notification is not UX friction. It is a financial event.

Adding a Sportsbook Without Breaking the Terminal

The strategic goal was clear: attract casual users without disrupting the professional workflows already trusted by experts.

The Sportsbook Hub — structured around live events, leagues, and coupons — was designed for the browsing behavior of casual bettors:

• find a sport,
• find a match,
• find a market.

It exists next to the trading terminal.

The navigation architecture routes each user type to the right entry point. Switching between them still feels like one product, not two separate systems stitched together.

The same architecture can scale to casino integration without changing the trading logic. The module already fits the structure. Adding it becomes configuration work, not surgery.

During design, this required discipline. There is always a temptation to reuse trading terminal UI patterns inside the sportsbook because they are already consistent and available. We intentionally kept them different enough so each flow would feel native to the user following it.

The Betslip That Failed A/B Testing Three Times

The hardest single UI element in the project was the price-comparison betslip inside the Trade section.

The requirement looked simple on paper:

• show odds from up to 12 bookmakers,
• let users choose the best price,
• execute the order,
• all inside a compact mobile layout.

The first version was logically correct but practically uncomfortable.

The hierarchy prioritized comparison before decision-making. Structurally it made sense, but in real usage it created friction. Users had to make an extra cognitive step that should not exist.

We ran an A/B test and adjusted the flow. The second version improved things, but friction still existed during confirmation. Users hesitated exactly where speed mattered most. In the third iteration, we changed the order of information instead of changing the information itself.

That version went to production. The lesson was simple: data-dense components cannot be validated only through design reviews, no matter how detailed they are. You need the right users, with the right mental model, under realistic time pressure.

Gabriel and James made this process possible. Every feedback session was technical, direct, and genuinely useful. No comments like “make the button bigger.” Real product feedback from people who work with order books every day.

The Main Lesson

Data density is never a layout problem. It is a mental model problem.

Design around the cognitive pattern of users making decisions under time pressure, and the layout will naturally follow. Design the layout first, and you will endlessly move pixels around trying to make things feel “good enough.” That is not the same as being correct. Understand whose mental model you are designing for before opening Figma.

Everything else is detail.

‍

MollyBet operates where fintech precision meets iGaming speed — a place where generic advice like “make the UI cleaner” is not enough. Our work in Sports Tech & iGaming and Product & Interface Design starts with domain logic, not design trends. Building a platform where UX is a competitive advantage? Let’s talk.

‍

Other articles in this series:

→ Design System With 981 Components: MollyBet’s White-Label Engine — link

→ MollyBet Gen Z: A New Product Built From the Same DNA — link

→ How We Redesigned the MollyBet Marketing Website — link