Coursera Email Design System
From reactive production to a design system teams could share
Cross-functional collaboration
Design systems
The short version
Email was one of Coursera's most important channels, but it ran on hundreds of one-off designs, built up over years with no source of truth.
Over two phases, I took email design from reactive to proactive to aligned. That meant a modular system for Degrees, then for consumer, enterprise, and product emails, timed to a platform migration and our rebrand.
I partnered with our email developer, directed three designers, and turned our email director into the system’s biggest advocate.
Design went from a production bottleneck to a strategic partner.
Pre-design system
Reactive, barely surviving
Design was stuck in a reactive loop: focused on production, siloed from the people sending email, and treated as decoration.
Email mattered a lot at Coursera. It was the second-biggest driver of new degree enrollments, and the biggest for MasterTrack. But it was also where design debt piled up.
Dozens of styles and layouts were live, some untouched since 2013. Nothing was standardized, so every request was built from scratch, eating up design and developer time. Emails were overly dense, there was no time to test anything, and learners got an inconsistent experience. And more than 60% of opens happened on a phone, so all of it had to work on mobile first.
Phase 1
Get buy-in, identify patterns, make it modular
Who’s involved:
Design lead, email developer, email managers, marketing managers
Get buy-in
Turning our email director into an advocate
People had to want a system, not just put up with one. I made the case in terms everyone cared about: consistency, efficiency, a shared language between designers and stakeholders, and the ability to scale. I partnered closely with Currin, our email developer, who owned the code while I owned the design. Building the system around everyone’s problems is what turned our email director into our biggest advocate.
I picked Degrees and MasterTrack emails as the pilot. They had the highest volume and the most marketing managers waiting on templates. Their content was small enough to automate, and their light Coursera branding gave us a neutral starting point before the rebrand. Then I met with each group to set requirements. Degree managers needed pre-built templates and partner branding. Email managers needed variants to test and clear guidance on limits and type. Dev needed mix-ins that pulled in logos and course details automatically.
Identify patterns
What every email had in common
Before designing anything, I laid the existing emails side by side to find what they had in common: the sections that kept repeating, and the variations that didn’t need to exist. The data pointed the same way: our emails were far denser than other companies’, and our best performer was a plain list of recommended courses.
Design modular system
Joining the pieces together
From those patterns, I built a style guide and a library of components that snap together into templates:
A clear hierarchy for actions
Buttons are only for the most important action. Secondary actions use text links. In long emails with 10 or more items, the card’s header becomes the link, so there isn’t a button on every card.
Partner branding built in
On Degrees emails, buttons automatically take on each university partner’s brand color.
One component, many layouts.
Guidance for every component and template
Every component and template shipped with guidance written right next to it: what each part is for, the image size to use, and how much copy fits. Headlines max out at 65 characters and three lines, subheads at 90, and buttons at 24. Templates were labeled module by module, from masthead to footer, so email managers could see exactly which pieces they were working with and swap them without breaking the layout.
Designing for the inbox
Email is a tough canvas. Every email had to stay under 100KB, hold up in dark mode, render in Outlook all the way back to 2013.
The hardest tradeoff was between style and content. Tests showed that more cards performed better. But every extra color, font weight, and layout change added code, and more code meant fewer cards fit. Currin and I worked through it together. Long, content-heavy emails got a simple, responsive design that could carry more courses. Short sends, like promotions, got more room for expression.
Build and test!
Templates go live
Ten templates covered the core jobs: general, interest sign-up, webinar, no-image, promo, about the program, application reminder, value props, stackable credentials, and schedule a call. I delivered the designs in four weekly rounds, finishing March 6. Currin coded them in April, our university partners reviewed them, and they launched in May.
1.0 Email Design System
Proactive, systematic design
With Degrees proven, design could get ahead of requests instead of chasing them.
Next, I extended the system to consumer, enterprise, and product emails. The consumer brief came in July 2020, and I designed through July and August so the new templates were ready six weeks before the September move to Salesforce Marketing Cloud. That way developers coded them once, not twice.
Value created by the 1.0 system
Design bottleneck
→
Empowering non-designers to create
Focused on each task separately
→
Shifting focus to user experience
Not sure what is working in designs
→
Time to test and experiment
No shared language
→
Collaborating with stakeholders
Service-oriented design team
→
Strategic partner in email streams
2.0 Email Design System
Scaling it across the company, through a rebrand
Then the rebrand came, and hundreds of legacy emails across Marketing and Product had to change, from teams starting in very different places.
We decided to use the rebrand as an opportunity to build alignment and establish processes to work together.
A company-wide design system
At the same time, Coursera was building its first company-wide design system, the Coursera Design System (CDS). Until then, Brand, Growth, Enterprise, Learner Experience, Core Platform, B2C, and WES each designed on their own. CDS brought them into one source for principles, component designs, and front-end code.
Part of a whole
CDS champions from each vertical made sure their team’s needs were built in by default. Email had to fit into that, so I kept the product team involved in email design decisions through the CDS work.
Compliance
Every email also had to be compliant: mostly text-based, with alt text, a view-in-browser link, unsubscribe, and legal language.
Phase 2
Scalable and reusable across every marketing email stream
Who’s involved:
Design lead, email developer, creative producer, email managers, marketing managers, product managers, product designers, engineers, production support
Audit & prioritize
Combing through 1,000 email templates
Our sending tools held more than 1,000 templates, many no longer sent. We defined “active” as more than 100 sends in 90 days, ranked those by volume, consolidated variants, and set what each one needed. Before launch I QA’d the top 200 product templates.
Design
Consumer and Degree email templates
I gave three designers their own working files and redlines, and directed them as they built emails from the system. We worked in two-week sprints with email and dev. When another team’s timing slipped, I moved the work that depended on them to a later sprint so everything else kept shipping.
Room to feel fresh
Five standard consumer templates covered the weekly send, new-course roundups, and promotions, with accent colors for seasonal moments.
Enterprise and WES email templates
Adopt and adapt CDS styles
I decided which CDS elements email would start using, and what to do when no CDS component fit an email need. The same mapping worked for teams on other tools. Enterprise emails ran on Marketo and were rebuilt by an outside agency, so I wrote the guidelines the agency built from and reviewed its modules. I mapped Marketo’s default styles to the system, and removed the ones that didn’t fit, instead of forcing a migration.
Document
Style guide and component guidance
I updated the email style guide to the new CDS foundations and documented every token, component, and template: what it’s for, its variants, and its content requirements. As new needs came up, components got smarter. Course card 2.0 added icons and color-coded labels, and swapped buttons for text links to save space.
Processes
A clear way to grow
New components followed a set process: submit a request, decide whether to take it on, define requirements, design, then build and test. Requests had a service-level agreement, so teams knew when to expect an answer.
Socialize
Getting the word out
I held regular training sessions with email managers across Degrees, Product, Consumer, Brand, Enterprise, and Sales, so non-designers could build on-brand emails on their own, and shared every update back with the CDS team.
ALIGNED
Making it last
Sisters, not twins. I worked with the CDS team so email and product felt like family. Where email had to differ, because of its technical quirks or to carry more brand, we documented why. Where a component was missing, I made the case for adding it.
The result
One system for every major email stream
By the end of 2020, every major email stream ran on one system.
Ten Phase 1 templates, more than 1,000 legacy templates audited, the top 200 product templates QA’d, and email managers on six teams trained.
Siloed design
→
Bridges built across teams
Disjointed user experience
→
Consistent design across touchpoints
Repeating the same work
→
Sharing resources, creating efficiency
Top-down approach
→
Collaborative design process
A colleague summed it up: "the first highly-scalable, executed Marketing design system ever in place at Coursera."
What I learned
Pick the pilot strategically
Starting with the highest-pain, lowest-risk emails gave us proof fast and won over the people who’d champion the rest.
A system is a service, not a file
The components mattered less than the documentation, training, and request process that let other people use them without me, from the designers I directed to the email managers.
Design with the developer, not for them
Working side by side with Currin meant the inbox’s limits shaped the design from the start, instead of breaking it at the end.
