Changing behavior so users migrate to a new email builder

Why the better product had low user adoption?

Mailchimp is the most widely used email marketing platform in the world. In 2020 it launched a new email builder, internally called "Nuni", to replace the classic builder, "Nea", a editor created in 2005 that was no longer supported and could not carry modern features like automation, AI, and generative content. Billions of emails were still being created on Nea.

Four years later, adoption had stalled at 26% of paid customers. Multiple teams had spent months adding features to Nuni without moving adoption or satisfaction. I joined the Core team of Mailchimp to change that.

What we did to change behavior

Research showed the resistance was about behavior, not features. I mapped it to the four levers of behavior change (adapted from the Fogg Behavior Model), which became the north star of the strategy:

• Ability. "I already know the old editor. Learning a new one takes time I do not have."
• Motivation. "What do I actually get for switching? If I invest the time, it had better be worth it."
• Prompt. "My workflow is built around the templates I already have."
• Recovery. "I tried it, had second thoughts, and going back to what is familiar felt safer."

“Behavior happens when Motivation, Ability, and a Prompt come together at the same time. When a behavior does not occur, at least one of those three elements is missing.”

Designing for Personas

To make the strategy land with leadership, I built it around a persona: Samira, a small-business owner who had run her email on Nea for years. I walked stakeholders through the migration from her point of view, what she would feel at each step, so the roadmap was a story about a real person, not a list of features. That narrative secured buy-in and reallocated engineering resources across teams.

Solution: Map the work, and create an execution plan that changes behavior

Rather than design more features blindly, I created and presented the migration strategy, with support from my manager, a UX researcher, and a content designer. The roadmap was backed by research and sequenced into phases tied to peak season, so the delivery was built toward the moment that mattered most for our revenue.

Phase 1, Ability: Feature parity

Nuni was missing basic controls that high-value customers needed, which made it a non-starter for them. I shipped these in incremental releases so people could build newsletters exactly the way they wanted: divider styles, border strokes, rounded corners, text background colors, button and image controls, social icon options, and more. Each release removed another reason to stay on Nea.

Phase 2, Ability: Replicate old emails into Nuni

Email templates were a crucial problem. Users felt that changing editors meant losing the hard work they put into creating templates. And 80% of paid Nea-only users relied on just their top 5 Mailchimp email templates, so supporting the most-used templates would make the majority eligible to move.

We initially aimed for 100% pixel accuracy, but user testing showed that content quality, proportions, and the placement of key elements mattered more than an exact match. We shipped at a minimum of about 91% pixel accuracy, which preserved what users actually cared about.

To validate replication quality at scale, Mailchimp's Futures team built a tool using the OpenAI CLIP model that scored before-and-after template pairs from 0 to 100. We benchmarked those scores against a moderated study with 8 small-business customers. The findings settled the debate:

• Customers rated the auto-migration about 87 out of 100 on average. CLIP scored it about 78, underestimating by roughly 9 points, which is the safer direction to be wrong in.
• 87.5% of customers said pixel-perfect migration was not necessary, which disproved the core assumption we started with.
• 100% said content parity was the single most important thing to preserve.
• 87.5% said they would send the auto-migrated email without any changes.

This is what gave us the confidence to ship at 91% rather than chase 100%, and it confirmed the design bet on content over pixel-perfection.

Phase 3, Prompt and Motivation: The flow that moves people over

I designed the flow legacy users would take to bring their old emails into Nuni, and A/B tested two approaches:

1. Ask users which builder they prefer.
2. Default to Nuni, with a clear option to revert.

Defaulting to Nuni with a revert option won. It nudged people forward while protecting the Recovery lever, the safety net for anyone having second thoughts.

Phase 4, Recovery: Re-onboarding

We reintroduced Nuni with a short, multi-step tutorial. It was a pragmatic call, not the ideal one: research shows people skip tutorials, and our layout options were limited. Given the timeline and resources, it was the right trade-off, and I am clear-eyed that it is the part I would revisit with more runway.

The outcomes

The roadmap reframed the work around the right problem, behavior change and template migration, instead of more net-new features. It refocused multiple teams and gave us a research-backed way to prioritize.

• Adoption beat the goal: about 55% Nuni-only adoption by Black Friday, against a 40% target, and it landed during peak season.
• Satisfaction improved: "very satisfied" CSAT rose from 62% to 69% by Black Friday. Short of the 80% goal, but a real gain at the highest-stakes moment of the year. (It also surfaced that free-tier CSAT lagged near 40%, a separate problem to tackle next.)
• Nuni tested as easier to use than competitors: in a benchmark on core editing tasks, Nuni scored 70% task success and 79.3 SUS (Grade A), against Klaviyo at 48% / 70.2 and HubSpot at 56% / 71.2 (both Grade C). I used this data to drive decisions and sell the strategy.

Takeaways

Before this, the team had spent months redesigning and adding features without moving satisfaction. The roadmap worked because it changed the question from "what should we build" to "which problem actually matters." That, plus securing stakeholder support and breaking down silos across teams, is what moved the numbers.

Knowing which problem to solve can be as important as being skilled at solving problems.