How I built Cosmos DS to translate MakeMyTrip designs into Goibibo styles without hours of repetitive manual work.
Sandeep BaralSenior Product Designer6 min read
Cosmos DS lets a designer choose the source and target systems, then convert the selected work.
One of the most fulfilling parts of working on a design system is finding ways to make the entire team faster. Cosmos DS began with a simple observation: our codebase was becoming unified, but our design workflow was still duplicated.
The codebase was unified. The design work was not.
MakeMyTrip and Goibibo are two travel platforms under the same parent company. As engineering moved both products onto a shared codebase, the design team still had to create a distinct experience for each brand.
A designer finishing a new Cabs or Bus flow for MakeMyTrip would duplicate the file, manually attach Goibibo styles, check variables, and repair anything that did not map correctly. The work was necessary, but it was repetitive and easy to get wrong.
Why native variable switching was not enough
Figma variables helped with new work built around them, but much of our product lived in older files. Those files used standard styles, detached styles, or library structures that were not perfectly aligned.
Legacy designs did not switch cleanly. Files created before variables still needed manual intervention.
Library swapping was fragile. Broken links appeared when the hierarchy of the two libraries differed.
Missing values had no dependable fallback. A design could retain an old colour or lose a style without making the problem obvious.
The team needed a way to translate both current and legacy designs while keeping the result visible and reviewable.
The goal was not to make designers better at repetitive work. It was to remove the repetitive work.
Building Cosmos DS
I built a custom Figma plugin around Cosmos, MakeMyTrip's design system. The plugin acts as a bridge between Cosmos and GI Foundations, the Goibibo design system.
A designer chooses the source and target systems, selects the relevant work, and starts the conversion. Cosmos DS reads the styles attached to each node, finds the closest named match in the target system, applies it, and keeps track of every node it changes.
The conversion stays transparent. Designers can follow progress and inspect applied, skipped, or unresolved styles.
How the mapping works
The core logic relies on the naming conventions shared across both design systems. For each selected node, the plugin reads the current style name, searches the target system, and attaches the best defined match.
Select the direction. Convert from MMT Cosmos to GI Foundations, or reverse the flow.
Build the style map. Match colour and text styles through the nomenclature of both systems.
Update and track nodes. Apply the target styles while recording what changed.
Review the result. Surface applied, skipped, and error states for focused QA.
This makes the conversion useful for complex components as well as simple screens. It also gives older files a route back into the modern, variable-driven system.
The detail that made it feel effortless
The largest source of friction in many Figma plugins is setup. I did not want designers to manually pull the target library into every file before Cosmos DS could work.
To avoid that step, I used Figma's REST API with a managed Personal Access Token. The plugin can read the exact style IDs from the master design-system files and attach them directly to the working file.
The token expires every 90 days and needs a quarterly administrator update. That maintenance is a deliberate trade-off: one scheduled update is much smaller than asking every designer to manage libraries for every conversion.
A completed conversion with a clear summary and a detailed audit trail for follow-up.
What changed for the team
Work that previously took hours of manual style swapping and QA could now begin with a single conversion. The result still needed design judgement, especially for intentional brand differences, but the mechanical part of the task was dramatically reduced.
Cosmos DS also made the output more consistent. The same mapping logic runs every time, exceptions remain visible, and designers can focus on the parts of the experience that genuinely need thought.
What I learned
Building Cosmos DS reminded me that a product designer's users are not always the customers using the final app. Sometimes the most important users are the designers sitting beside us.
A design system creates real leverage only when the workflow around it is designed with the same care. The plugin succeeded because it did more than automate a technical task. It made a tedious process feel clear, safe, and easy to trust.
