Turning a rebrand into a Design System transformation

Using a company-wide rebrand to make the Design System worth adopting.

I joined Sendinblue (which will 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 generally saw the value immediately. Indigo made Figma work faster and helped bring consistency to an organization scaling quickly.

For Engineering, the equation was different.

Migrating from existing libraries meant additional work, with very little immediate reward.

That resistance was legitimate. We were asking teams to change how they worked without yet giving them a compelling reason to do so.

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: 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 look and feel too early.

By D-Day, Naos foundations were already embedded throughout the product.

04 — Adoption became a shared product responsibility.

We used the Design System to turn the AI experience into a shared, buildable foundation for product teams across Brevo.

The first step was to bring teams into the journey.

We brought Product Managers and Designers together to imagine what Aura could eventually create across Brevo, from campaigns and automations to reports, segments, tasks, and CRM objects.

Beyond identifying shared needs, the workshop created momentum around Brevo's new AI direction, giving teams a concrete way to explore what the Augmented CRM could mean for their own domains.

This work helped us prioritize the first foundations: Global Aura surfaces, artifact patterns, previews, and the DS components required to support them.

My team and I designed these foundations, then worked with our DS engineers to bring the first MVP into production.

This shell is intentionally evolving, designed to expand as new use cases, capabilities, and agentic interactions emerge.

AI is also pushing the product to evolve.

These explorations revealed something broader.
Designing AI experiences isn't only changing how users interact with Aura, it's exposing opportunities to rethink Brevo itself.

Generated artifacts, conversational inputs and agentic actions challenge interactions originally designed for traditional workflows.

We are not adding AI on top of the existing product. We are using it to explore what the next Brevo experience should become.

05 — Testing the system before shipping it.

The experience framework is taking shape, while the agentic architecture behind it still requires time, experimentation, and validation.

None of these experiences are live today. As the underlying architecture continues to evolve, we are using prototypes to test the experience against real product use cases and learn what the system actually needs.

Generating an SMS campaign

Creating an SMS campaign showed that a prompt alone isn't always enough to generate the right artifact. This led us to introduce refinement questions, both as a new foundational AI capability and a new interaction pattern in the Design System.

Generating a Segment

Creating a segment challenged another assumption: not every artifact needs a preview. Depending on what is being created, the artifact itself can provide enough context to understand and act.

06 — From AI ambition to a shared product direction.

The outcome isn't a finished AI product yet. It's a shared foundation for what Brevo's AI experience can become.

What started as an ambition to make Brevo more intelligent became a common model for how intelligence and experience should work together across the product.

The framework gave teams a shared direction, reusable foundations to build on, and a way to explore new AI use cases without creating disconnected experiences.

The work continues as the agentic architecture matures and new use cases emerge. But the foundation is now in place for Brevo to evolve toward the Augmented CRM.