Overview
The problem
The product had accumulated years of parallel work across teams that didn't share tools, patterns, or foundations. Mobile and desktop were designed in separate libraries. Tokens didn't exist. Components were built differently depending on who made them and when. Designers working on one surface had no reliable way to know how their decisions would translate to another.
The engineering side reflected the same fragmentation: four frontend engines meant four places to maintain every change, four interpretations of every design decision, and four potential points of failure with each release. Product speed was suffering.
My role
I led the design system for OneFrontend end to end. That meant defining the architecture, building the Figma library from scratch, establishing the component system, and working directly with engineers and stakeholders to align on every foundational decision: grids, breakpoints, token structure, component behavior.
This was the largest design system project in LiveJasmin's history, and the first time a single library covered every surface, device, and user type across the platform.
The approach
Starting from the right foundation. Before building anything visible, I worked with engineers and stakeholders to define the decisions that everything else would depend on: the grid system, the token architecture, and the breakpoint set. These couldn't be changed later without cascading consequences, so they needed to be right from day one. That alignment process across design, engineering, and product was itself a significant part of the work.
Atomic system architecture
The library is structured on atomic design principles atoms, molecules, organisms, templates and pages. Every component is built with auto layout, constraints, and responsive behavior baked in. Nothing requires manual adjustment when switching device context. The system is built to flex and to support 4 breakpoints: SM=390px ; MD=768 ; LG=1024 ; XL=1280.
Tokens - a first for LiveJasmin
Design tokens had never existed at LiveJasmin. Every color, spacing value, and typographic property was defined as a token before a single component was built. Tokens gave the system a stable reference layer: engineering consumes it directly in code, and designers update any value in one place and watch it propagate across the entire library.
Auditing before building
A product with 20 years of accumulated UI decisions doesn't give you a clean slate. Before defining anything new, I mapped what existed across the product surface — cataloguing every component pattern in active use, every spacing value applied, every color in production, every inconsistency between desktop and mobile. The audit made the scope of the problem concrete and gave the stakeholder conversations a shared evidence point.
It also protected the migration: knowing exactly what was in production meant the new system could be designed to cover every real use case, not just the ones that were easy to anticipate. Nothing we built was theoretical every decision was grounded in something the product already needed.
One library for every device
I replaced the separate mobile and desktop libraries with a single unified library covering desktop, tablet, and mobile. Every component adapts to its device context from the start, so a change made once lands on every platform no duplicated maintenance, no second source of truth to keep in sync, no drift to chase down later.
The breakpoint switcher
The most significant workflow improvement I introduced was a custom breakpoint switcher built into every page template in the library. A designer working on a page can switch between desktop, tablet, and mobile views with a single click the layout, spacing, and component sizes all respond automatically. This eliminated the need to design screens separately for each device. What used to take hours of parallel work now happens in seconds. It changed how the entire design team operates.
Scope of the system
OneFrontend covers the full product surface: visitor pages, free user flows, member flows, profiles, payment flows, security pages, terms and legal pages, listing pages, the applet hundreds of screens across every user type and context. The library needed to support all of it without becoming unmanageable. The atomic structure and token layer made that possible.
The goal wasn't just a new Figma file. It was a complete reset of how design and engineering worked together with a system that could scale across one of the most complex products in the company.
Migration strategy
The migration to OneFrontend was designed to be gradual page by page, not a full rewrite. A rewrite would have concentrated all the risk in a single release and frozen product delivery for the duration of the transition. Instead, the system was built to coexist with legacy code, so new pages and features could move onto the platform incrementally while the old engines kept running.
Library atomic system architecture.
Color tokens showcase of Primitive and Semantic collection.
Figma breakpoint switcher algorithm.
Key decisions
Not every decision in this project was about design. Some of the most consequential ones were about process, architecture, and convincing a large team to change how they worked. These are the choices that defined the system not just what it looked like, but how it would hold up over time.
DECISION 1
🎯
One library, not two
Merging mobile and desktop into one library went against how the team had always worked, and the transition cost was real. I made the case that a short learning curve was worth permanent coherence. Within weeks, one source of truth stopped being a debate and became the default way the team operated.
DECISION 1
👀
Breakpoint switcher as a design tool
The real decision was making responsiveness a property of the library instead of a task for the designer. That shift removed an entire category of repetitive work from every project and set a new baseline for how fast a page moves from first idea to ready on every device.
Outcome
OneFrontend gave LiveJasmin a design system that finally matched the scale and complexity of the product. Designers move faster because responsive behavior is handled by the library, not by hand. Engineers build from a cleaner, more consistent reference.
A designer can now open one file, work on one component, and know it covers every device. Design and engineering share a token layer instead of a translation process. The full product surface from visitor landing pages to payment flows to the applet lives in a single coherent system.
The migration from four frontend engines to one is a long-term program. The design system is the foundation that makes it possible.
75%
Reduction in frontend
maintenance overhead
3×
Faster responsive
design delivery
60%
Reduction in design to
development handoff cycles
METRIC 1
75% reduction in frontend maintenance overhead
Consolidating four frontend engines into one platform means every change is implemented, tested, and deployed once instead of four times eliminating roughly three quarters of the repetitive engineering effort attached to every release.
METRIC 2
3× faster responsive design delivery
Designing desktop, tablet, and mobile previously required three separate design passes per page. With responsive behavior built into every template, a single pass now produces all three device views simultaneously.
METRIC 3
60% reduction in design-to-development handoff cycles
Tokens, full state coverage on every component, and a single source of truth removed most of the back-and-forth that used to define handoff. Questions like "what does this look like on mobile?" or "what's the disabled state?" are now answered by the library itself.