Industry
Gaming
Client
tombola (Flutter)
Role
Lead Product Designer
Full House Design System
Overview
Full House is the design system we built at tombola to reduce inconsistencies, support multiple brands, and help designers and developers move faster. It started as a way to bring structure to a growing set of products — and turned into a shared foundation for everything we design, build, and ship.
Why this mattered
Things weren’t broken, but they weren’t working smoothly either. Without a central system, we relied on memory, Teams chats, and digging through old files. As we added new brands and teams, it became clear we needed something more reliable. It worked — for a while. But as new brands and teams joined, keeping everything aligned became harder, slower, and more prone to confusion. We needed a shared foundation that could support how we were actually working, not just how we wished we were.
What I did
When I joined, the design system already existed — but it wasn’t consistent, complete, or ready to scale. Some components worked, some didn’t. There were gaps in structure, logic, and documentation. I took a step back and reviewed everything component by component. My goal was to make sure each element had a clear purpose — not just from a design perspective, but from real usage across brands and teams.
That meant:
Involving other designers early, so decisions weren’t made in isolation
Testing patterns, validating edge cases, and refining components based on real product needs
Reworking naming, structure, and logic for better adoption
Making sure documentation explained not just how something works, but why it exists
Ensuring the system could adapt to different markets, themes, and levels of complexity
Supporting collaboration with developers and QA to keep things realistic and scalable
This wasn’t about building a perfect system — it was about making it solid enough to rely on, and flexible enough to evolve.
How we approached it
First, we audited what we had. Then we structured components by priority and relevance. For each one, we asked: Is this solving a real need? Is it designed for more than one brand? Does it scale across themes and use cases? We involved other designers in decision-making early on, encouraging feedback and open discussion. Where needed, we ran small validations to test patterns or flows before locking anything in. Tokens came next. We restructured the foundations around brand flexibility and theme support — including light/dark modes — with clarity and consistency in naming. We documented everything in parallel: not just the how, but the why. And throughout, we kept developers and Product Managers involved. The system grew step by step. Not perfect, not finished — but solid, practical, and ready to support real product work.
Outcome (so far)
Full House is now in the hands of the wider company — not just the design team. Adoption is happening gradually, as more squads choose to use the system to build new features, clean up old ones, and keep things consistent across products. The goal is for Full House to become the default way of working — a shared tool that helps us move faster, design smarter, and avoid reinventing the wheel every time. We’re still working through components, one by one, and gathering feedback from everyone involved: designers, engineers, PMs, and other stakeholders. It’s not just about what looks right — it’s about what works across the board. The system isn’t “done”, but it’s being used — and that’s the best way to make it better.
What's next
We’re still working through components, improving adoption, and making sure the system fits the way teams actually work. As more squads use Full House, we’ll continue reviewing what’s there — and what’s missing. Some components will evolve, new ones will appear, and others might disappear altogether. Once the system is fully rolled out, I’ll update this case study with outcomes, lessons, and the things we’d do differently next time.
Keep exploring