Litmus Design Library
The Tension
Litmus had a retention problem. The platform was the industry leader in email testing and tracking, letting customers render email code across 90+ clients like Outlook, Apple Mail, and iOS Mail. But the usage pattern was brutally episodic: a developer would sign up, test an email, then cancel. 90% of revenue came from this cycle.
In 2019, leadership wanted to change the equation. The goal was to bring value across the entire email development lifecycle, not just the testing phase. If Litmus could become essential to how teams build emails (not just test them), retention would follow.
The business goals were clear:
- Reduce episodic usage by giving people a reason to stay beyond testing.
- Drive plan upgrades by adding features worth paying more for.
- Add new users through collaboration features that pulled in entire teams, not just individual developers.
My Role
I was the Product Design Lead responsible for developing solutions that would tackle these business goals through product innovation. I partnered with data science, product management, and our internal email team throughout.
Discovery
I interviewed over 20 customers, drawing from both existing Litmus users and non-users for a broader perspective. I also synthesised previous internal research and worked closely with the data science team to understand current behaviour patterns.
The core problem was straightforward: email developers were not productive when building new emails. Every email is built modularly, from reusable blocks like headers, title sections, image blocks, and footers. But there was no good way to manage these blocks.
What we found
- New content blocks were rarely created from scratch. Teams reused what they had.
- There was no single source of truth. Blocks were maintained by copying from old emails.
- Workflows were hacky and fragmented across multiple tools.
- It was difficult to scale for larger teams. Emails went out of date quickly.
- Code was stored in Google Docs. Organising it was painful.
- New developers joining a team couldn't find up-to-date code. Onboarding was slow.
The opportunity was clear: maximise developer productivity by giving teams a proper home for their reusable templates and content blocks, with the quality and consistency controls they were hacking together manually.
The Solution
The outcome was Design Library: a first-of-its-kind tool in the email marketing space that let developers build, store, and manage reusable code blocks that could be applied to any email. Think of it as a design system, but for email HTML components. Templates, headers, buttons, footers, content blocks, all version-controlled and accessible to the whole team.
This didn't exist before. Email developers had been using home-grown solutions, spreadsheets, and shared Google Docs to approximate this workflow. Design Library gave them a real tool.
Design Library integrated directly into Litmus's existing Builder, the email code editor. Developers could pull components from their library while building, ensuring consistency across every email their team sent. A component updated in the library would be available everywhere.
Evidence
After extensive beta testing, the product was launched to production following four weeks of successful validation.
- 42% of beta users created at least one Design Library component within 30 days of launch. That's adoption velocity you rarely see with a new product surface.
- 14% of beta users transferred their entire email assets to Litmus, learned via signals from customer support. This was the stickiness we were after. Once your design system lives in Litmus, you're not cancelling after one test.
- Builder usage increased by 24% within the beta cohort and 18% after general release. More time in Builder meant more value derived from the subscription.
- Reduced shared logins. Previously, teams shared a single account. Design Library gave teams a reason to add individual seats, because each person needed their own workspace. This directly drove plan upgrades and revenue growth.
- Early retention signals were strong. Customer support reported users requesting features to move their entire email design systems into Litmus. That's the kind of lock-in that comes from genuine product value, not switching costs.
What I Learned
The biggest insight was that Litmus had been thinking about itself as a testing tool, and its customers had internalised that framing. Changing that perception was harder than building the product. Some users didn't immediately understand why their testing platform was now offering a component library. There was an education gap that needed bridging alongside the product launch.
The other lesson: the best retention features aren't the ones that make it hard to leave. They're the ones that make the product more valuable the more you invest in it. A Design Library with three components is useful. One with your entire email system is indispensable. That compounding value is what turned episodic users into long-term customers.