Email designs often get reviewed in the worst possible format: one long image pasted into a deck or attached as a PDF. The client scrolls past it, comments on the hero image and approves. Then the email goes out with a subject line nobody reviewed, a preheader that says “View this email in your browser” and a sender name that reads like an internal system.

Those three lines decide whether anyone opens the email at all. Here’s how to run a review that covers them, along with the design.

Start with the inbox view

Before anyone looks at the design, show what the reader sees first: the sender name, the subject line and the preheader, sitting in an inbox. This is the part of the email that has to earn the open, so it deserves its own moment in the review.

Ask the client to read it the way a customer would. Is it clear who it’s from? Would they open it? Does the preheader add something, or just repeat the subject?

Review the subject line as part of the design

Subject lines often get written last, by whoever has five minutes. Put them in the design review instead, next to the email they belong to. A few guidelines help:

• Put the important words first. Many phone inboxes show only the first 30 to 40 characters.

• Make the preheader work. It’s a second line of copy, not a place for “View in browser”.

• Match the promise to the body. A subject that oversells the email teaches readers to ignore the next one.

• Offer two or three options. Choosing between options in context is faster than writing from a blank line.

Show the whole flow, not one email at a time

A welcome series, an abandoned-cart sequence or a product launch is a set of emails that should read as one story. If you send them for review one by one, the client never sees that the second email repeats the first, or that the tone shifts halfway through.

Present the flow together, in order, with each email clearly labeled. Then review each one in detail.

Check how it reads on a phone

A large share of email gets read on phones, so look at the design at phone width before the client does. Check that the headline still reads, the buttons are big enough to tap and the main message appears before the first scroll. If you design a separate mobile layout, show it next to the desktop one.

Separate design review from rendering tests

A design review answers “is this the right email?”. A rendering test answers “does this email display correctly in Outlook, Gmail and Apple Mail?”. Both matter, but they’re different jobs that need different tools. Get the design approved first. Then build it and test the HTML with your email platform’s previews or a dedicated testing service such as Litmus or Email on Acid.

Mixing the two leads to clients commenting on rendering quirks in a static mockup, or approving an image the final build doesn’t match.

An email design review checklist

• The sender name is one the reader will recognize.

• The subject line makes sense in the first 30 to 40 characters.

• The preheader adds information instead of repeating the subject.

• The main message and call to action appear before the first scroll.

• There’s one primary action, and its button says what happens next.

• The email still makes sense if images don’t load.

• The unsubscribe link, legal lines and postal address are there.

• Prices, dates and promo codes are correct.

• The design works at phone width.

• Every email in a flow has a clear job and doesn’t repeat the one before.

How email review works in Honter

Honter’s email view shows each design inside a mail-style frame, with the sender, subject line and preheader where the reader will see them. Upload one design per email and each one gets its own tab, with an overview that shows the whole flow at once.

• When you set up the project, Honter can suggest a subject line and preheader from your designs.

• Your client gets a sparkle next to the subject that offers three subject lines of 35 to 60 characters and three preheaders of 40 to 90. They pick one, tweak it or write their own, and everyone sees it live.

• AI reviewers read the copy before the client does. In email the Translator leads, flagging lines that will land differently than you meant, and the subject, preheader and sender are part of what it reads.

• Clients pin comments on any section of the email and can switch between light and dark.

Honter reviews the visual design. It doesn’t render HTML or test across mail apps, so keep your testing tool for the build stage.