Initiative
Syncing design assets with real components
Yandex Fleetroom
Michael rebuilt the component library for Fleetroom by aligning design assets with the actual frontend implementation. The previous system lacked structure, used unsupported layout patterns, and caused confusion between designers and developers.
By replacing loosely defined components with production-aligned building blocks and introducing clearer workflows, he helped reduce errors, improve collaboration, and enable reuse across multiple product teams.
Product
Fleetroom is a b2b platform used by taxi companies operating under the Yandex and Yango brands. It supports both b2b and b2c workflows, helping partners manage drivers, vehicles, and finances. Yandex primarily serves the CIS region, while Yango operates in select African and Latin American markets.
Human context of the product by Medialab. Michael was not involved in producton
Fleetroom reused elements of the Yandex Taxi business unit’s design language – including brand colors, overall design approach, and domain-level concepts. The product was tightly integrated into the ecosystem and became the main consumer of the internal b2b design system, which supported multiple tools across the business.
Over time, some of the inherited design choices created friction. Not all approaches were supported by the design system team, and the gap between design and frontend gradually widened. This made the system harder to maintain and limited its ability to scale.
What he did
When Michael joined the team, the design library didn’t meet the needs of designers or developers. Components were being added, but didn’t reflect frontend structure. Teams used different terms, followed different patterns, and lacked a shared review process.
Part of the library reused assets from another product within the same business unit. While they shared branding and terminology, the components were built for different purposes.
Imagine trying to build one car using parts from another – same brand, same colors, same goal – but a totally different structure
Another issue was the lack of production-aligned assets in Figma. Although the design library included representations of components, many were overrides of reused elements rather than proper components.
They didn’t reflect the actual structure or include updates made in code over time. The only way to see how a component really worked was to inspect it in Storybook or directly in the product – a slow and error-prone process.
The team also relied on slot-based layouts – flexible containers for nested content. These sped up layout work in Figma, but didn’t match how components worked in code.
After confirming with engineers that slot behavior wasn’t implemented, Michael flagged the misalignment. Designers could create layouts that couldn’t be built, leading to recurring issues.
He proposed retiring slot components where they weren’t supported by code. To move forward, he aligned with his manager, design leadership, and consulted the original author of the slot approach, who had also moved to a more structured model.
With leadership support, Michael led a full redesign of the Figma library to match frontend implementation. Each component reflected real structure, states, and constraints.
He also introduced a more structured workflow. By using branching in Figma, the team could separate draft work from production-ready assets. Together, these changes helped shift the team from fragmented assets to a shared, maintainable library used across products.
Before. Everything lived in one file – concepts, unfinished work, production components. No separation, no status, no lifecycle
After. The library file reflects production only. Work happens in branches: explore, review, and merge when ready
Outcomes
The updated library included over 40 production-ready components, each structured to match the frontend implementation. Components reflected actual code constraints and state logic, reducing ambiguity during design and handoff.
The improvements resolved shared issues across several products. Teams, including those without dedicated designers, adopted the new assets with minimal onboarding. Designers reported fewer implementation issues, reduced reliance on Storybook, and less back-and-forth with engineering during specification and review.
The library became the default starting point for interface design in at least four products. Figma analytics showed a steady increase in component usage, with core patterns such as buttons, inputs, and lists becoming the standard in new design work. Michael kept the library aligned with production through regular Storybook-based updates.
Learnings
The project demonstrated that system quality relies as much on shared structure, ownership, and communication as it does on component design. Without alignment between design and development, even well-defined assets can lead to misinterpretation and rework.
Michael replaced flexible, slot-based layouts with components that reflected actual frontend constraints. This reduced ambiguity and made the system more scalable across teams.
The core effort, however, lay in managing trade-offs, aligning stakeholders, and shifting design practices to support consistency at scale. In this context, clear constraints proved more effective than open-ended flexibility – particularly in a multi-product environment with distributed contributors.
He also recognized that long-term value depends on usage. Beyond rebuilding the library, he focused on embedding it into daily workflows, helping designers adopt structured habits that reinforced system reliability.
The experience reinforced his focus on enabling clarity through systems, alignment, and maintainable design infrastructure.