If your product lives mostly in code, not in Figma, you don’t have a design system — you have a collection of one-off decisions. I help turn that reality into a structured UI system teams can actually reuse.
Context
Many products grow faster than their design foundations. UI files become scattered between tools, components evolve without rules, and developers are forced to rebuild patterns from scratch. The result is always the same: inconsistent experiences, slower releases, and design decisions happening directly in code.
I’ve seen this across very different environments — from established iGaming platforms with fragmented Sketch and Figma files, to SaaS startups with no design assets at all. Despite the differences, the core problem was identical: without a shared system, every new feature became more expensive and less coherent.
My role in these projects was to turn that chaos into a practical, developer-friendly design system — a single source of truth that teams could actually use to move faster, not another theoretical framework.
Challenge
Both environments faced the same underlying problem: product growth had outpaced its design foundation.
• iGaming: Source files were incomplete and inconsistent, while multiple live products relied on slightly different UI patterns. The challenge was to create a system that respected existing implementations without freezing future development.
• SaaS: With no design assets at all, the interface lived entirely in code. Rebuilding the system meant reverse-engineering real components, aligning them with user needs, and creating a structure developers could adopt without a full rewrite.
In both cases the goal was not a “perfect library,” but a practical system that could be introduced into an active product without slowing delivery.
Work Process
Across both projects, I applied a consistent methodology:
- Audit & Reverse Engineering: Analysing existing interfaces to identify patterns, inconsistencies, and opportunities for improvement.
- Building New Design System Using Atomic Design Methodology: Designing reusable components, from atoms to templates, ensuring scalability and flexibility.
- Developer Handoff & Documentation: Delivering a structured system with clear guidelines to streamline collaboration and maintain long-term consistency.
Atomic Approach
I use an atomic structure because it mirrors how products are actually built. So rather than designing screens, I design components. An atomic model keeps the system predictable: small elements combine into larger patterns that both design and development can understand.
This creates a shared language across teams and prevents the gradual drift that usually happens when products evolve feature by feature.
Single Source of Truth
The effort spent decomposing the UI pays off immediately: components become reusable across multiple products. Developers can reference the same elements in Storybook. And the last but not least — new features can be build from existing patterns instead of exceptions.
The system becomes a foundation for growth, not another design document.
Results
The system replaced guesswork with a clear structure:
- A single, reusable component library for design and development.
- Consistent patterns across previously fragmented interfaces.
- Fewer one-off solutions and less rework.
- Faster delivery of new features without visual drift.
Most importantly, the design stopped being a bottleneck and became a reliable part of the product workflow.
