Process

iGaming Design System: How We Built BoxBet From Components, Not Pixels

Roman Danyliuk from flatstudio
Written by
Bohdan Kononets
Roman Danyliuk
Category:
Process
15 April 2026
12 min read

This article is part of the Flatstudio × BoxBet case study. BoxBet is a crypto iGaming platform with a component-based design system built for a complex product stack. CEO of BoxBet — Christian. For product designers, frontend developers, and tech leads building or scaling a design system. Main article of the series — here.

An iGaming product is simultaneously a casino, a sports platform, a Telegram app, a promo machine, and a crypto ecosystem. Each section runs at its own pace, but users move between them in seconds. When components don't agree across sections, you feel it immediately. Not as a bug — as estrangement.

The BoxBet design system was built for that reality.

Who and How

The system was built by our design lead Roman Danyliuk. Design leadership — on me. Roman and I had already been through 24 sportsbooks before BoxBet — which means the structure, the typical failure points, and the critical components for this type of product are already known to us going in. Same with how to best structure a design system for developers.

At BoxBet we built from scratch. As thoroughly as possible. With an emphasis on making sure developers never had to ask for clarification.

What's Inside

Figma file structure: Design System, Components, Navigation & Sidebars, Modals & Notifications, Banners & Graphics. Each section is marked with a green icon — all components connected to code via Code Connect.

  • BoxBet is a large product. In projects like this, chaos usually sets in: components scattered across files, names that don't match, a new team member spending a full day just getting oriented. We follow a strict approach to structure — files divided by categories and subcategories, every element exactly where you'd expect it. That makes life easier for all teams simultaneously and keeps Figma itself fast: large files without logic lag, logically organized ones don't.
  • Colors. Brand (Primary, Brand Gradient, Secondary, Tertiary Dark), Background from 0 to 30, Grey from 90 to 0, Transparent (White 0.6, Overlay, Ghost), Red, Green, Gradients (Stroke, BXBT, Fade, Gold), Shadows. A separate block — VIP Colors: Unranked, Silver, Gold, Platinum, Diamond, Master, Legend, God+. Eight colors, each tied to a VIP program level and the corresponding Lucky variant.
  • Typography. Hubot Sans in four roles: Heading (Desktop and Mobile), Body, Label, Caption. Heading Desktop starts at H1 SemiBold 40/42 and steps down to H2 Bold 18/20. Label has separate lowercase and caps styles stepping from 16 to 12. Caption — two variants for long-form text: 14/20 and 12/15. A complete scale with no gaps.
  • Components. Icons, Buttons, Tabs Controls & Dropdowns, Events, Table, Inputs, Headline Rows, Betslip. Each with all states, variants, specifications, and the ability to scale any feature easily. Add something or remove it — nothing breaks. Everything is built on auto-layout and design best practices, which directly simplifies work in Dev Mode.

Components You Don't Find in a Regular Product

Betslip and Events are iGaming-specific components. You won't find them in a standard SaaS product.

Betslip is the bet slip. It's present on every page of the sports section, updates in real time, and carries complex internal logic: singles, accumulators, odds changes, acceptance errors. One component, dozens of states.

Events are match blocks. They display odds, statuses, live indicators, leagues, time. They look simple, but behind them is a matrix of dozens of variants depending on event type and state. Different sports, types of odds, different languages.

Navigation Across Four Worlds

BoxBet has four main sections: Casino, Sports, Promo, Profile. Each one is a standalone product in terms of scope. The navigation's job: at any moment, on any page, at any screen size — desktop, mobile, Telegram App — the user gets where they need to go in one click or tap.

We designed Navigation, Left Sidebar, Mobile Left Sidebar, and Right Sidebar as a single system that adapts to context. No extra burgers or dropdowns where they can be avoided.

One specific solution — navigation between pre-match and live. From the pre-match page, the user can switch to live without going back to the homepage or opening a burger menu. From live — to pre-match with a specific time window. We'd already worked out this pattern on Parimatch and in a template for a gambling provider — here it landed naturally.

This kind of solution affects both SEO and behavior: fewer steps means more time on the platform.

The Banner System Inside the Product

A dedicated block in the design system — Banners & Graphics. This is the banner system for hero slide blocks on the BoxBet site: header, casino, promo, sidebars.

The component has clearly defined rules for four screen sizes: 1920, 1440, 768, and 360. There are resizing guidelines — how the banner behaves when the container changes size, how background blur works, where the safe zones for text are. Marked as "Ready for dev" — a developer opens the file and starts building without questions.

How this banner system connects to the full BoxBet marketing graphics — in Article 3.

Dark Theme — and the Potential of Light

All our design systems are built with the ability to quickly switch between dark and light themes. This is baked into the tokens and color variables from the start.

BoxBet ended up with only the dark theme. The client decided — and it's justified for an iGaming platform where dark interfaces are the industry standard. But if the need for a light version emerges in the future, the system is already ready for it.

One 20-Minute Zoom — and Almost No Questions After

When the development team received the files, we ran one shared call. Twenty minutes. Roman walked through the structure: where everything lives, how to read the components, how Dev Mode is organized. After that, developers went into the file on their own — and almost no questions came back.

Compared to similar projects where they'd worked with other design teams, questions dropped by a factor of three.

That's about how a component is described: which states are covered, where the behavioral boundaries are, what happens to spacing when content changes, clean file, logical structure. A design system is a UX product in its own right. If designers don't have a design system, or it's unclear and messy — what kind of product are they going to build? That's a rhetorical question.

We Don't Just Draw

In some places we didn't stop at handing over a Figma file. When developers ran into something complex to implement, we went further and prepared working CodePen examples: how something should look, how it should animate, how it should behave.

  • Banners — a concrete example of how the hero slide block should animate on the site. The developer opens it and sees live behavior, not a static layout with annotations.
  • But we went further than just transition animations here. We implemented the complex carousel behavior ourselves: the background changes based on the type of banner — static photo, graphic, or video. Each slide has its own content type, and all of that variation lives inside one carousel where everything switches smoothly and at the right pace. When we first described this idea to the developers, they went quiet for a moment. It turned out to be a genuinely difficult technical problem. We built a working CodePen and handed it over as a ready solution.
  • Buttons — states, hover effects, timing. Everything that Figma describes approximately, shown here in motion.
  • Font fix — developers couldn't connect Hubot Sans correctly and get the right render. We solved it at the code level and handed over the fix.
  • Logo animations — several variants of how the BoxBet logo can appear and disappear. The client chose one, and the developers received the ready code.
  • Game card micro-interactions — hover behavior for game cards in the casino. The detail that separates a live interface from static markup.

This is part of our approach: a design system only lives when it's implemented the way it was intended. Sometimes that means taking a step toward code.

The Failure We Caught in Time

We designed a complete sports section: navigation between markets, branded leagues for promo campaigns, top match blocks, hot combos for quick bet entry. Separately — an SEO architecture with interlinking and clean transitions on both mobile and desktop.

All of it landed on the table and didn't make it into the product.

The client couldn't build the sports section in their own codebase within the available timeline. They had to take SoftSwiss — a ready-made solution with limited customization options. Most of the sports components stayed in Figma.

This came up in Article 3 already — both the sports section there and here had the same root cause: technical constraints of the platform overrode design decisions that were ready to ship.

Twenty-Four Sportsbooks Before This One

BoxBet is the twenty-fifth sportsbook in our experience. Which means most decisions that look like fresh ideas actually grew out of previous projects.

Betslip with all its edge states? Already worked out. Navigation between live and pre-match? There's a template. VIP color system with gradient transitions? We know exactly where it breaks.

Experience in iGaming design systems is accumulated edge cases that aren't documented in any design guide.

The System That Holds Everything Together

The identity set the language (Article 1). The mascot gave it a face (Article 2). Promo mechanics and marketing multiplied that language across dozens of channels (Article 3). The design system made sure all of it stayed coherent at the code level.

BoxBet looks like one product because it is one — from a color token to a betslip component, from the website to the Telegram app.

Need a similar design?
Contact us
Authors
Bohdan Kononets
CEO and Design Director
Roman Danyliuk from flatstudio
Roman Danyliuk
Product Design Lead
FAQ

Frequently Asked Questions

Who are these solutions best suited for?

We design around complex, high-stakes products rather than simple marketing sites. Our solutions are best suited for B2B and B2C SaaS, fintech, sports tech and iGaming teams dealing with high-load dashboards, internal tools, betting platforms or multi-platform ecosystems. Most of our clients are startups and scale-ups that need a consistent design and engineering partner instead of a one-off creative studio.

What’s the difference between a fixed‑price sprint and a long‑term retainer? 

Fixed‑price sprints (like Fundraising Concept or Product Audit & Discovery) have a clearly defined scope, timeline and deliverables — for example, a 4‑week concept sprint or a 2–3 week audit. They are ideal when you need a sharp, focused outcome. Long‑term retainers (like Post‑MVP Evolution or Dedicated Product Units) are built for continuous evolution: we join your roadmap, work in sprints, and adjust priorities as your product and metrics change. You get a predictable monthly budget and an embedded team instead of re‑negotiating every feature.

How do I choose between Pitch Deck & Product Concept, Post‑MVP Evolution, Product Audit & Discovery, and Product Rebuild & Redesign?

Pitch Deck & Product Concept is for 0→1 founders who need to raise capital before writing production code – we turn your vision into an investable narrative and clickable concept. Post‑MVP Evolution is for Seed / Series A teams with a live product that needs faster iteration, stronger UX and a real design system. Product Audit & Discovery is for products facing churn, stagnation or negative feedback – we diagnose UX and tech friction and give you a prioritised roadmap. Product Rebuild & Redesign is for mature or legacy platforms that have hit a growth ceiling – we modernise brand, UX and code without breaking the business logic that already works. If you’re unsure, we start with a short discovery call and map your current stage to the right model.

How is "Engineering Design" different from a regular creative agency?

Regular agencies optimise for “wow” moments and campaigns. We optimise for systems and product performance. We treat design like code: modular, scalable and logic‑driven. Instead of drawing standalone screens, we build design systems, patterns and documentation that your developers can implement without guessing. That’s why our solutions always combine product & interface design, brand identity, web app engineering and marketing assets into one coherent system.

Do you work with startups or only established companies?

Both. Our clients range from early-stage founders raising their first round to enterprise teams scaling complex platforms with millions of users.

What do clients value most about working with Flatstudio?

Clients consistently highlight three things: deep industry knowledge, logical and scalable design systems, and honest communication. We challenge weak decisions early rather than executing them blindly.