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

Building the design system nobody asked for

0->1 Design Systems

Figma Plugin Dev

Crypto/Gaming

Ai-Assisted Workflow

Component Architecture

The first internal product designer at a crypto gaming startup. No design foundation, no component library, just a live product with many game types, built by developers, moving fast. I built the system from scratch, shipped color tokens to codebase, wrote a custom Figma plugin to generate components at scale, and onboarded the next designer onto it. All while everything else was still shipping.

TIMELINE

August 2025 - Present

TEAM

Engineers
Me as designer

TOOLS

Figma
Claude

THE SITUATION

I walked into a product that five people had clearly built five different ways.

When I joined, I was the first internal product designer the company had ever hired. Which sounds exciting, but it also meant walking into a product that had been built entirely by developers, moving fast, with zero design foundation.

Casino games, sports betting, live table games, all on the same platform, all looking completely different. Neon buttons everywhere in different sizes and styles. Inconsistent padding. A previous designer's leftover styles that nobody was using. Developers making their own UI calls because there was nothing else to reference.

No shared language meant every new feature was a fresh negotiation about what things should look like.

THE OPPORTUNITY

The devs wanted to rebuild the site. I started building before they finished the sentence.

Introducing a design system into a live product is all about timing. When the team is already planning a rebuild, that's your moment. I didn't pitch a proposal or wait for approval. I just started. I didn't try to sell the whole system upfront. I started with the things that were already breaking. Got those in front of developers, and let the wins do the convincing.

goals

Nobody asked me to build this. I built it anyway.
‍The company's priority was shipping. Speed was the culture, and a design system is a hard sell. But I was the lead designer on a product with no shared foundation, no reusable components, aligned color styles and I could see exactly what that was costing us every sprint.

Behind each of these was the same business reality: every hour a developer spent rebuilding a component was an hour not spent on growth, retention, or new features.

01

Make the product consistent
‍across all game types without slowing down shipping.

02

Give developers something to build from independently.
‍No more on-off design decisions.

03

Stop rebuilding the same components every sprint.
Features always started at zero.

04

A foundation for the 2nd designer.
‍Something documented and learnable.

THE PROCESS

I didn't get a dedicated sprint. I built it between everything else.

This wasn't a clean project with a dedicated sprint. No design system ticket in Jira. It happened in the gaps, between other projects.

01 Audited everything first

Before touching anything, I needed to understand the full scope of the mess. I screenshotted every component on every page and catalogued what existed.

Some discoveries:
• 12+ grey shades in use across the product and no logic to which should be darker or lighter
• 4+ primary button styles - different sizes, different border radii, different shades of color
• No button hierarchy - primary, secondary, ghost all fighting for attention on the same screen
• No visual consistency - icons from different libraries, illustrations from various designers

Auditing site, games and noting inconsistencies

02 Foundations: color, type, spacing, radius

I built the token layer. Color first - a full semantic surface scale, brand greens, text hierarchy, feedback states. This took real time to figure out. What should be lighter vs. darker, how grayscale behaves in a dark gaming environment. I tested every token against every surface it touches from panels, drawers, to modals.

Then I cross-referenced with the codebase. I worked with an engineer to map what existed as CSS variables, reconciled the naming, and got the tokens implemented.

Color token system alongside CSS variable implementation

03 Component variables & states

Once foundations were in, I built out component variables: interactive states (default, hover, active, disabled, focus), feedback states (error, success, warning), size variants, and content variants. Every component had to work across all the contexts it'd appear in before it went into the library.

Input box component state coverage

04 Built components while learning the games

In order to design the right components, I had to actually understand the games. I played on various platforms to understand good experiences. I had to figure out how each game worked and what states existed. Then I standardized elements across every game types so they could pull from the same library.

Updated multiplier game panel

Standardizing game components: labels, player avatars, footer

Building components also meant fixing real product problems.

‍The tabs component is a good example. We had more games than users could find, no filtering, no way to surface recently played or originals. I mapped out every context it needed to work in, lobby navigation, game filters, history, each with slightly different behaviour.

Tab component states & variants

04 Used AI to move faster.

Working solo on a project this size meant I had to be smart about where I spent time.

Token naming and conventions. I used Claude to pressure-test naming logic across the entire system. AI caught inconsistencies I'd have missed.

‍Component gap analysis. Claude helped map which components were missing, which had incomplete variants, and what needed to be built before the system was production ready. Structured breakdown by category with notes on why each component was needed.

Grace's Script Runner plugin + DS component gap analysis

‍Wrote a custom javascript plugin in Figma.
For components with large variant sets, I wrote a JavaScript plugin to generate them programmatically. The plugin builds the full set, labels everything, positions it on the canvas. Doing it manually would have added weeks.

Connected Claude to Figma via MCP. So it could read the existing component structure directly and generate certain components that conformed to the same rules.

components deep dive

Some components needed more than consistency. They needed a rethink.

While building the system, I kept finding components where the problem wasn't just visual inconsistency. It was that the existing design was actively hurting the experience. Components like broken feedback states and confusing game panels aren't just design debt. They're churn risks. I prioritized the ones with the highest user touchpoints and the most direct impact on trust and engagement.

the feedback system

How do we build a feedback system that scales across every game, every error, every edge case?

The Problem: Every win felt like a warning. Every notification had a countdown timer.
Success, error, warning, they all looked identical and they all felt urgent. In a product where a user's first win or a smooth deposit moment should feel good, that's a retention problem. Anxiety where there should be delight erodes trust fast, and trust is the whole game when real money is involved.
‍
So first, I did an audit. Screenshotted every feedback state across the platform to see what existed, and then went into the codebase to find every toast.error and toast.success call. That research surfaced six distinct error types that were all being handled the same way: session errors, balance errors, field validation, neutral info, success states, all with the same styling and the same timer.

Feedback system before

Once I understood the full scope I built the system. Three types with clear rules: ephemeral toasts for quick info that auto-dismiss in two to three seconds, status toasts for things worth noticing, and action toasts for anything that needs a decision with a clear CTA. Each type documented in the design system with variants, timing, sentiment, and real copy written for each case.

After - three types with defined behaviour and real copy

game panel deepdive

The most-used UI on the platform had never been looked at holistically.

The problem: Every game had built its own version of the game panel.
‍Every game had built its own version of the game panel. Same platform, completely different layouts, different button hierarchies, different rules for where settings lived. Important actions hidden in a carousel. Large empty space on desktop. Nobody had ever zoomed out and looked at this as a system. This mattered because this UI element every user touches on every session. Inconsistency here isn't a polish problem, it's a conversion problem. A confusing panel means slower decisions, more errors, and users who don't come back.

I started by auditing every game panel and mapped inconsistencies. I realized the games fell into two groups with fundamentally different needs.

‍Multiplier games: The panel needed to be minimal, quick to interact with, and completely out of the way of the game itself.
‍Table games: The action happens in the centre of the screen. So I pushed the panel to the bottom to keep the centre clear, surfaced the most used chip values immediately without a carousel, and made the action hierarchy obvious at a glance.

Four things shipped: a standardized table game panel, a standardized multiplier game panel, a global footer component for settings and rules, and a unified visual style for game assets across the platform.

Game panel audit

Game panels after: One-shared system

beyond the components

The visual language needed fixing too.

Game thumbnails were coming from an agency doing anime-style illustrations, AI-generated images from developers, assets from multiple freelancers. All on the same lobby page with nothing tying them together. I rebuilt every game thumbnail in Figma into one cohesive style, rewrote the brand copy and tone across the product, and prototyped hover states and card flip micro-interactions for the thumbnail system.

game thumbnail redesign

Rebuilt every game thumbnail in Figma into one cohesive style and rewrote the brand copy and tone across the product.

From mismatched agency styles to a single cohesive visual language.

adding interactions to components

I prototyped hover states and micro-interactions for the thumbnail system.

Final player avatar designs and components

Icons had the same problem.

Different libraries, different stroke weights, different sizes. A 16px icon next to a 24px icon next to something with a 1px stroke and something with a 2px stroke. It read as noise, not UI.

I consolidated everything into a single icon library with one stroke weight and one size grid. Then documented the guidelines so any designer or developer could pick the right icon without asking

Icon library - grid rules, keyline shapes

what changed

What this unlocked for the team.

120+ components with full state coverage. 3+ products running on the system. Designers and devs working more independently. From no design culture to a team that defaults to the system first on every new feature.

Onboarded our second designer onto the system.

Walked them through token structure, component naming logic, how to use the library, when to extend versus create something new. Before this there were no colour styles, no text styles, no component states. Now design work that used to take months takes weeks. Full game interfaces that required weeks of back-and-forth can be turned around in days.

The hardest part wasn't building 121 components. It was convincing a startup that moves fast and ships fast that slowing down to build this properly would make everything faster. That argument is a lot easier to make when the system is already working.

Lessons learned

Honestly, I learned a lot more than I expected to.

I had to think like a PM. 120+ components solo meant constantly triaging. What's breaking things right now, what's blocking developers, what has the most surface area. Prioritizing was its own skill.

I genuinely got better at components. You don't really understand a component until you've designed every state, tested it across four game types, and documented it for someone else. I came out a much better component designer than I went in.

Constraints made it better. Working solo meant I couldn't build everything, so I had to be smarter about what I built and when. I learned how to actually use AI properly and how it can help save time.

I got comfortable in the codebase. Not as a dev, but enough to be useful. I went in to check how tokens were actually being used, fixed spacing inconsistencies, badge sizing, hardcoded colors that should've been variables. When you've seen how your decisions land in code, you stop making ones that create unnecessary work for engineers.