From HTML dependency to no-code email infrastructure.
Owned the component architecture and design system for Mastercard's global email builder — defining what got built, why, and in what order. The constraint wasn't brand. It was Outlook.
The real constraint — email client compatibility
No div support · tables only · breaks modern CSS
Inconsistent font rendering · dark mode issues
Good HTML5 support · dark mode needs extra handling
Strips head styles · inline CSS required
Reliable · good responsive support
Variable rendering across Android versions
Every design decision was filtered through: “Will this render in Outlook Desktop?”
Client
MastercardCreative Studio
Role
Design System LeadComponent architecture + governance
Duration
6–8 months+ ongoing feedback iterations
System
50+ components28 templates · 9 categories
Constraint
Outlook DesktopDrove every design decision
Adoption
Mastercard-wideBacked by Global Brand team
The Problem
Mastercard's brand evolved. Its email system hadn't.
Operational problem
Custom emails required HTML knowledge. Teams either depended on agencies — slow, expensive, inconsistent — or avoided custom emails altogether and defaulted to outdated generic templates. After the Mastercard.com rebrand, the gap between the updated digital identity and downstream email communication became immediately visible.
Technical problem
Even when teams had HTML skills, Outlook Desktop's lack of modern CSS support meant hand-coded emails regularly broke. Div-based layouts failed. Dynamic buttons required workarounds. Font handling was inconsistent. No standard, no governance, and no system to prevent it from happening again.
The central tension
Teams wanted richer, more branded communication. Outlook Desktop — still dominant across enterprise — couldn't render it. The design system had to make the best possible email within the worst possible constraint. Simplicity wasn't a design preference. It was an engineering requirement.
My Role
Three people. Three clear ownership boundaries.
I didn't build the builder UI and I didn't write the HTML. I owned what went inside both — the component architecture, design standards, governance model, and prioritisation of what to build next.
Senior Engineer
HTML + Builder Code
- ·HTML email implementation
- ·Builder platform development
- ·Email client compatibility fixes
- ·Outlook-specific workarounds
- ·Responsive email coding
You — Design System Lead
Component Architecture + Governance
- ✓Defined what components to build and why
- ✓Modular architecture decision
- ✓Design standards and governance
- ✓User research and feedback loops
- ✓Prioritisation of roadmap
- ✓UX guidance and strategy
- ✓Simplicity-over-complexity calls
- ✓Global Brand alignment
Designer
Builder Dashboard UX
- ·Builder interface design
- ·User flows within the tool
- ·Template selection experience
- ·Dashboard and preview UX
- ·Authoring interaction patterns
Key Decisions
Modular reusable components, or bespoke one-off templates?
Problem
There was pressure to build 28 beautiful, hand-crafted individual templates. Faster to deliver, great for launch optics. But every future brand update would need to touch every template individually.
Decision
Fought for a component library that teams assemble into any email layout. Started as a Figma library concept — designers create layouts themselves, then hand off for HTML build. Evolved into the no-code builder.
Tradeoff
Required more upfront investment in architecture that wasn't immediately visible to stakeholders. The compounding benefit only became clear over time, when a brand update touched one component — not 28 templates.
Impact
A brand update now propagates through every template by changing a single component. New email types are assembled from existing pieces, not built from scratch. The system scales without the effort scaling with it.
Push for design ambition, or design within the Outlook constraint?
Problem
Stakeholders wanted richer, more visual emails — multi-column layouts, custom fonts, dynamic CTAs. Outlook Desktop couldn't render any of it reliably without complex, brittle workarounds.
Decision
Every time a stakeholder pushed for more visual complexity, the answer was to simplify the design rather than push for complex engineering workarounds. Outlook Desktop is the floor, not an edge case to hack around.
Tradeoff
Required repeatedly saying no to stakeholders who wanted more — and having Global Brand's endorsement to hold that line. Without organisational authority backing the governance model, it would have eroded on day one.
Impact
The constraint produced more durable design. The emails that perform best in enterprise environments are rarely the most visually complex. Simplicity wasn't a compromise — it was the correct answer.
Build a powerful feature-rich tool, or keep it simple enough for anyone to use?
Problem
The biggest adoption problem wasn't technical capability — it was intimidation. Teams avoided custom emails because HTML felt too risky. A more powerful tool with a high capability ceiling would solve for power users and fail for everyone else.
Decision
Radical simplicity: any non-HTML person should be able to build a branded email. Select a component. Fill in content. Ship it. No code, no design tool, no external vendor required.
Tradeoff
Power users wanted advanced customisation, pixel-level control, export options. Those use cases were left underserved intentionally. The 80% case — any team, any region, on brand — mattered more than the 20%.
Impact
Teams that previously avoided custom emails because HTML felt too risky began creating richer branded communication more frequently. Removing the HTML requirement changed the behaviour, not just the tooling.
System Architecture
Four levels. One coherent system.
Foundations are stable. Components are reusable. Patterns are assembled. Templates are shipped. Each level builds on the one below — and a change to any level propagates upward automatically.
L1
Foundations
Spacing system, typography hierarchy, brand colour tokens, responsive grid, accessibility standards, and email-safe colour system. These never change.
L2
Components
50+ modular building blocks — hero banners, CTA modules, content cards, editorial blocks, product highlights, event modules, legal footers. All Outlook-safe.
L3
Patterns
Recurring email structures assembled from components — campaign layouts, launch announcements, newsletters, internal comms, event invitations.
L4
Templates
28 best-practice templates across 9 communication categories. Mastercard-wide. Every template is a composition of L2 components — update a component, update every template.
The Outlook Problem
What we wanted vs. what Outlook could handle.
Every time we wanted to do something modern, Outlook Desktop said no. Here's how every major design decision was reshaped by that constraint.
Template Library
28 templates. 9 categories. All Outlook-safe.
Every template is assembled from the component library — not built from scratch. Updating a component updates every template that uses it.
Newsletter
Recurring communications
Announcement
Product + org updates
Event Invite
Conferences + webinars
CEO / Leadership
Executive messaging
B2B Campaign
Partner + sales comms
Product Campaign
Feature launches
Information
Updates + notices
Internal Comms
Employee messaging
Other
Edge cases + custom
Adoption strategy — the feedback loop
Building the system was half the job. Getting teams to actually use it was the other half. Regular interviews with power users drove iteration on real workflow friction.
The Shift
From HTML knowledge required to anyone can build a branded email.
Before — manual HTML workflow
<table width="600" border="0" cellspacing="0">
<tr><td style="padding:0;margin:0;">
<!--[if mso]><v:rect...>
<div style="color:#000"> <!-- breaks in OL -->
<p style="font-family:Arial;">
<!-- font ignored in Outlook 2016 -->
Hello [FIRST_NAME],
<!-- spacing broken on mobile -->
</table>
HTML required
Agency dependency · inconsistent output · weeks of turnaround
After — no-code builder
Zero HTML required
Any team · any region · on-brand · Outlook-safe
The organisational shift
Teams that previously avoided custom emails — because HTML felt too risky or agency turnaround was too slow — began creating richer branded communication more frequently. The barrier wasn't capability. It was confidence. Removing the HTML requirement changed the behaviour, not just the tooling. That's what a well-designed system does: it changes what people feel able to do.
What Changed
A system the whole organisation adopted.
Backed by Global Brand. Used Mastercard-wide. The number wasn't how many components shipped — it was how many people stopped needing HTML to communicate.
Barrier to creating a branded email
What it took to send a branded, Outlook-safe email.
Before
HTML + agency
After
Zero code
M.01
50+
Modular components — all Outlook-safe, all brand-compliant.
M.02
28
Best-practice templates across 9 communication categories.
M.03
9
Communication categories covering the full range of Mastercard messaging needs.
M.04
Zero HTML
Skill level required. Any team, any region can now build a branded email.
Key Reflection
The challenge wasn't creating email templates. It was designing a system constrained enough to work in Outlook and flexible enough that any team would actually want to use it. Governance only works if someone with authority backs it.
The governance lesson
I faced significant stakeholder pushback on the governance model — people wanted more flexibility, more exceptions. Global Brand's endorsement was what held the line. Design systems need political backing, not just design quality. The best-designed system gets ignored without organisational authority behind it.
Adoption is a design problem
Building 50+ components and 28 templates was the visible work. The less visible work — training, feedback loops, iterating on friction, making the system feel safe to use — was equally important. Systems that don't get used don't exist, no matter how well-designed they are.
Constraint as creative direction
Outlook Desktop forced every design to be simpler than I wanted. In retrospect, that constraint made the system more durable. The emails that perform best in enterprise environments are rarely the most visually complex. The constraint was frustrating in the moment and correct in the long run.
What I'd do differently
I'd have instrumented usage from launch — tracking which templates got used most, which components got customised, which categories drove the most adoption. That data would have accelerated the feedback loop and made the prioritisation conversations much sharper.
Keep reading