Designing email with room for the build

By Gyata Tabiri · Revised October 30, 2026

My design background matters when I build an email. A fallback is a visual decision too, and I want it to preserve the message rather than simply satisfy a technical requirement.

Set the reading order

Decide what someone should notice first and what they should do next. Show how columns stack, how the message changes at a narrow width, and how much copy the design can accommodate. A mobile layout is an editorial decision as well as a change in width.

Make the important details explicit

Identify live text, decorative images, destination links, and anything that depends on a particular font or background. If the design uses text over an image, review the alternative when that image does not appear. A clear solid-color treatment can be an intentional part of the design.

Invite a technical review early

I have flagged layout, background, and button issues that led designers to revise their work. Sharing a screenshot or discussing a coded sample is more useful than describing a feature as simply impossible. It gives the team something specific to evaluate.

Agree on acceptable differences

The aim is a coherent message across the chosen environments. Record what must match closely, what can adapt, and which differences are acceptable. That agreement helps both design review and QA stay focused on the reader rather than an unattainable promise of identical pixels.

An early coded example gives the designer and developer a common reference. It makes room for a considered compromise while changes are still manageable, rather than leaving the final review to resolve the whole disagreement.

My Little Pony campaign study · Discuss a role or project

Reference: Background-image fallback guidance.