Case in progress
Turning a rebrand into a Design System transformation
Using a company-wide rebrand to make the Design System worth adopting.
I joined Sendinblue (soo to become Brevo) to increase adoption of Indigo, the existing Sendinblue Design System, and turn it into more than a component library: a shared product foundation, platform, and language across teams.
A few months later, Sendinblue began its transformation into Brevo. Rather than treating the rebrand as a visual migration, I used it as an opportunity to rethink the value of the Design System for the teams expected to adopt it.
That transition became the foundation for Naos, Brevo’s Design System.
Company : Brevo — European SaaS CRM unicorn, serving 600,000+ customers globally across Marketing, Sales and Customer Experience.
Role : Unified UX and Design System Manager
Scope : Design System Strategy · Product Foundations · Rebranding · Change Management · Design Leadership
Timeline: July 2022 – May 2023, with adoption + DS management continuing afterwards
Collaboration: Brand · Product Design · Product Management · Engineering
01 — Indigo existed. The reason to adopt it didn't.
When I joined, Indigo already had good starting foundations.
A small set of core components was implemented and used in production, generating around 400 component insertions each month.
The bigger challenge was adoption.
Ownership and governance were still unclear, legacy UI libraries remained deeply embedded in the product, and teams could often move faster by building custom interfaces or continuing to use what they already had.
Designers saw immediate value in a system that made Figma faster and brought consistency to a rapidly scaling organization.
For Engineering, the equation was different. Migrating meant replacing working implementations with additional effort and little immediate reward. Building custom or continuing with existing libraries was often simply easier.
The challenge wasn't convincing teams to adopt the system. It was giving them a reason to change.
02 — The rebrand changed the equation.
Instead of running two competing transformations, I connected Design System adoption to a change that every product team would have to make: the rebrand.
Two months after I joined, Sendinblue started preparing its transformation into Brevo: a new name, identity, colors, and product experience.
Every team would eventually need to migrate while continuing to ship.
I saw an opportunity to connect the rebrand with Design System adoption. Instead of asking teams to migrate for the sake of Indigo, the Design System could become the safest way to prepare for Brevo.
Migration shifted from extra work to a way of reducing future work and launch risk.
The goal was no longer simply to evolve Indigo, but to use that transition to establish Naos as the shared foundation of the new product identity.
03 — We designed the bridge from Indigo to Naos.
Teams had to continue building new features at scale while simultaneously preparing for a full rebrand, without exposing the new brand before launch.
Working with Brand, I owned the translation of the new identity into product foundations while deliberately building on what was already working in Indigo.
We structured the existing styles into tokens across color, typography, spacing, shadows, and border radius, improved existing components, and created the ones needed for the rebrand.
The key decision was theming.
We built Sendinblue and Brevo themes across Figma and Storybook — before Figma variables existed.
Teams could migrate away from legacy implementations months before launch without introducing the Brevo brand too early.
By D-Day, Naos foundations were already embedded across the product.
Switching to Brevo became a theme change rather than a product-wide rebuild.
04 — Adoption is a collective effort.
A Design System team can build the system. It can't adopt it.
Adoption only happens when the teams building the product choose to move with it.
That meant making migration a shared responsibility across Product, Design, and Engineering, not a Design System objective pushed from the center.
We connected adoption directly to rebrand readiness, aligned leadership around shared objectives, and made migration part of each team's priorities.
Together, we mapped the product into P1, P2, and P3 migration scopes, giving teams a clear path to move progressively onto Naos ahead of launch.
Migration started in February, four months before D-Day.
With a central team of initially two engineers and me — later three engineers and a junior designer — our role wasn't to migrate the product ourselves. It was to give teams the direction, foundations, and support to do it themselves.
05 — D-Day turned adoption into trust.
Naos proved it could reduce work, not add to it.
The rebrand launched with a new identity, a full theme switch, and a redesigned navigation, with no rollback.
For Engineering, the value became tangible: less local maintenance, shared fixes and improvements, and accessibility handled more consistently at system level.
Engineers who had once been reluctant began checking whether designs were compliant, whether components already existed, and how new work should fit into Naos.
The shift was simple:
“Why should I migrate?”
→ “Are we using the system correctly?”
That was the real change: Naos moved from a system teams were asked to use to a shared foundation they actively protected.
06 — From adoption to a shared product foundation.
The rebrand accelerated adoption. The work since then has been to scale Naos while making product behavior more consistent and easier to evolve.
Over time, monthly component insertions grew from:
405 → 16,341 → ~40× increase
Jul 2022 to Jul 2026
As adoption increased, we kept expanding Naos while streamlining shared behaviors, patterns, and contribution across the product.
The system gradually moved from a central library to a shared foundation teams could build on, contribute to, and use to scale proven solutions.
People adopt change when the value becomes theirs.