Email Development
Brand Email NewslettersBDG
Production HTML email templates built across 12 newsletters for 9 BDG editorial brands.
Type
Professional
Role
Product Engineer
Stack
HTML, CSS, Litmus
Timeline
2024
01
The Problem
The infrastructure didn’t exist yet.
BDG operated multiple editorial brands and wanted email newsletters to drive both reader engagement and advertising revenue. The infrastructure to support that didn't exist yet.
The deeper challenge wasn't just building templates. Email rendering across Outlook, Gmail, and Apple Mail is deeply fragmented. The wireframes came from a web-native design team, so they included border-radius, SVGs, background images, and layout patterns that all needed re-evaluation before they could ship reliably.
02
Constraints
Each brand, built from scratch.
Each newsletter required its own implementation. Component designs varied by brand, CSS was custom per build, and table structures weren't always shared. Prior work served as reference, but each brand needed its own development pass.
Where wireframes included patterns that wouldn't hold up, I evaluated the intent, found a compatible alternative, and documented tradeoffs when the change had meaningful visual impact. Cross-client validation with Litmus ran continuously throughout each build, not as a final phase.
03
My Approach
Working within email’s limits.
Email development meant table-based layouts and a limited range of CSS properties. Consistent styling often required heavy use of !important. Several common patterns surfaced recurring rendering issues, especially in Outlook.
Border radius
Rendered inconsistently between Gmail and Outlook, making rounded elements unreliable
SVG assets
Decorative headers and themed bullet icons weren’t reliably supported across clients
Background images
Had inconsistent support across clients, particularly in Outlook
Spacing behavior
Only worked reliably on <th> and <td> elements, not <table> or <tr>.
Halfway through the project, the original design lead left the company, so I began making implementation-level design calls on my own and communicating tradeoffs directly.
04
Interaction & UI Decisions
Table-based, tested continuously.
The system was built entirely on table-based layouts, the only reliable structural foundation in email. For each brand I implemented the full set of required content layouts: headers, article collections, two-column grids, alternating feature layouts, bulleted list blocks, paragraph sections, product collections, quote blocks, and emphasized content modules.
Spacing and layout were handled through <td> attributes and external stylesheets, with inline styles as a fallback for cross-client consistency. Validation ran continuously via Litmus across Outlook, Apple Mail, and Gmail. When Outlook surfaced issues, templates were revisited as part of the normal workflow rather than a final QA step.
05
Implementation Details
Designing within the constraints.
Email doesn't have the interaction surface of a web UI, but layout and visual hierarchy decisions still matter. A few consistent decisions shaped how layouts were adapted across builds.
Consistency over client-specific polish
When a treatment worked in Apple Mail but broke in Outlook, the default was to simplify rather than split the implementation
Wireframe adaptation as a design decision
Some elements were simplified, others replaced with compatible alternatives. Layout intent stayed intact where possible
Unicode as a practical tool
Replacing SVG bullet icons with Unicode characters preserved visual intent, improved reliability, and removed asset management overhead for editors
06
Outcome
Shipped across 9 brands over 6 months.
All 12 newsletters shipped incrementally over the 6-month rollout. Each send reached approximately 100,000 unique opens. Leadership recognized the newsletter initiative as a quarterly highlight and cited its contribution to new advertising revenue.
12
Newsletters shipped
9
Brand implementations
~100K
Unique opens per send
07
Reflections
Email humbled me.
This project sharpened my understanding of building for constrained rendering environments. It pushed me outside modern CSS into a more restrictive set of rules where much of what I knew didn't apply.
Looking back, there were a couple of process improvements that would have reduced rework across brands.
Earlier Outlook checks
Adding an Outlook validation pass earlier in each brand’s cycle would have reduced late-stage rework
A running constraints reference
A living document of known constraints and workarounds would have created a reusable checklist and stronger handoff support for future contributors