How I QA my own email designs before they go to a developer

The most expensive place to find a design problem is after development. The second most expensive is during development. The cheapest, by far, is in Figma, before any code has been written.

A revision caught during the design review takes minutes to fix. The same revision caught after a developer has built the template, tested it across clients, and handed it back for feedback can take hours. Multiply that by a high-volume email program and the compounding cost becomes significant.

Over the years I've built a personal QA pass that I run on every email design before it leaves my hands. It's a checklist I run in Figma, methodically, before I share anything. Here is what it covers.

Run through this before every handoff.

☐ One clear focal point,  the layout reads in under three seconds
☐ Natural flow from hero → body → CTA with no competing elements
☐ Layout reads clearly when zoomed out to 50%
☐ Body copy is at least 14px, line height 1.4 or above
☐ No light text on white that becomes invisible when backgrounds invert
☐ Logos and icons with transparent backgrounds survive dark mode inversion
☐ Every CTA is at least 44px tall with passing color contrast

Visual hierarchy check in three seconds

The first thing I do is step back from the design and try to read it as a stranger. Not as someone who built it, but as someone opening an email on their phone between meetings.

The questions I ask: Is there one clear focal point? Does the eye move naturally from the hero to the body to the CTA, or does it get lost? Is there a single most important thing, and does the design make that obvious?

A lot of email designs have strong individual components that compete instead of work together. Hierarchy problems are easiest to see when you squint at the design or zoom out to around 50%. If the structure isn't clear at a glance, it won't be clear in an inbox.

Typography fallback review

Once the hierarchy is clear, I check the typography against the fallback scenario. If this email renders in Gmail web and the custom font is stripped, how does it look? I keep a Figma component that swaps the brand font for the system fallback stack and apply it as a quick sanity check.

The things that break most often: headline sizing that worked in the brand font but creates awkward line breaks in Arial, tight letter-spacing that becomes unreadable at fallback size, and body copy that was set at 13px because it "looked fine" in the designed font but is too small in a system font at mobile scale.

Dark mode simulation

Dark mode email rendering is not a single behavior. Different clients invert differently, apply their own color filters, or do nothing at all. Apple Mail applies an aggressive automatic inversion unless you explicitly opt out. Outlook on Windows darkens backgrounds. Gmail on Android uses a partial inversion.

I simulate dark mode in Figma by duplicating the design and manually applying the approximate inversion that would be produced. This catches the two most common problems: logos or images with transparent backgrounds that disappear against dark surfaces, and light-on-white text that becomes invisible when the background flips.

CTA and touch target audit

Every CTA in the design gets measured. Minimum height 44px. Minimum width that comfortably contains the copy with padding. Sufficient color contrast against the background (WCAG AA requires a 4.5:1 ratio for normal text, 3:1 for large text).

I also check that CTAs are not stacked too close together. On mobile, two buttons placed within 20px of each other are a tap accuracy problem. If the design calls for multiple CTAs, there needs to be enough space between them that a thumb can hit one without accidentally triggering the other.

Image weight and alt text

Every image in the design should have a defined alt text. Not as a legal formality, but because a meaningful portion of subscribers read email with images turned off, and alt text is the fallback that keeps the message legible. I note the alt text for every image in my design specs.

I also flag any image that looks like it might exceed a reasonable file size once exported. Heavy images carry a real performance cost that shows up in load times and deliverability. The design review is the right moment to ask whether a background image is worth the weight, not after the template is coded.

Accessibility pass

Color contrast, font size, link distinguishability. I use the Figma Contrast plugin to check every text-on-background combination. The email accessibility checklist for 2026 is a practical reference for the full set of standards lifecycle teams need to meet.

The AI-assisted final pass

The last thing I do is describe the email design to Claude and ask it to flag anything I might have missed: unclear hierarchy, accessibility concerns, copy that doesn't match the intended tone, or module sequencing that might confuse a reader. It functions as a second reviewer with no attachment to the decisions already made.

This is not a replacement for the human checks above, but rather a catch-all for the things you stop seeing after you've stared at the same design for an hour. It fits into a broader AI-assisted email design workflow worth reading alongside this process.

The developer should receive a design that is as close to final as it can be before they write a line of code. This process is how I get there.