Building a design system while migrating the admin
Nuvemshop’s admin had to be rebuilt on a new front end, and Nimbus, the company’s first design system, was built along with it. The job: migrate fast without breaking the experience, and turn what didn’t fit into a better system.
Over about 8 months, starting in late 2021, I migrated key areas of the admin, took the lead on the system’s usage documentation and acted as a bridge between product designers and the Nimbus team. The opportunities we found along the way fed Nimbus v2, released in February 2023.
The problem
Nimbus was the company’s first design system, created together with the admin migration. Every legacy screen had to be rebuilt on it while the system itself was still taking shape.
The constraint
This wasn’t only a UI change: the migration also replaced the underlying front-end infrastructure, which made a gradual, screen-by-screen rollout technically impossible. Product teams kept shipping in parallel, so every screen had to move without slowing delivery.
The Nimbus team tracked adoption with coverage: the share of each product’s front end built with Nimbus components, with a target above 90%.
Migrate first, then evolve
The system and the migration were moving at the same time, which forced a choice:
Perfect the system first. Design a complete, flexible Nimbus before moving more screens. Cleaner, but it would hold the migration back for months.
Migrate on v1 and learn. Move screens fast, live with v1’s gaps for a while and log every improvement opportunity for the next version.
We chose to migrate first. I believed that moving fast on v1 would get the whole admin onto one system sooner and give us real evidence for v2, because the opportunities would come from production screens, not assumptions.
What we gave up. Ideal solutions per screen. I mediated conflicts between the new and the old interface, reconciled tickets as they came in and focused on low-hanging fruit instead of redesigning every flow.
Migrating, documenting, connecting
Admin areas I migrated. Custom domains, home and onboarding, statistics, customers, plus recurring iterations on the main menu and navigation.
Usage documentation. A collaborative effort that I led: criteria for when to use one component over another, not just how each one looks. It started on v1 and was carried into v2.
Bridge between teams. Critiques with product designers and conversations with developers surfaced where components weren’t flexible enough. I turned those into concrete requests and iterations with the Nimbus team.
Adoption you can measure
Coverage, tracked by the Nimbus team, showed the system holding up after v2: between February and August 2023, average coverage across products rose from about 86% to about 92%, above the 90% target.
The same tracking measured overrides, the share of components customized inside products. Where overrides stayed high, it pointed to exactly the kind of flexibility gaps we had logged during the migration.
Results and learnings
What improved. The whole admin moved to Nimbus, and v2 shipped more flexible, shaped by the opportunities we found in real screens.
What got worse. Mapping every legacy screen to its new version in a short window was disruptive for merchants who already knew the old admin. It generated a wave of support tickets and some dissatisfaction, and it made the impact of each change hard to isolate.
What I’d do differently. If the technical constraints allowed, or for a future version of Nimbus, I’d iterate piece by piece: tokens and small components rolled out over months, to reduce disruption and measure the impact of each change on its own.
Coverage figures come from the Nimbus team’s tracking. Screens are simplified illustrations.