Email Delivery Transparency for High-Stakes Messaging

01 · Discover and define

Cordial's enterprise email clients needed to know, in real time, whether a high-stakes send was actually working. Two client quotes captured the gap:

Abercrombie: "Is my message sending and how much longer will it take?"
L.L. Bean: "Did something go wrong with my message and how do I know?"

The existing Email Sent Messages table: a flat list with a hover-only status flyout buried in a small icon

A design evaluation of the existing interface surfaced concrete usability failures: hover-dependent interactions that violated Jakob's Law, disrupted navigation per Fitts's Law, and critical status details buried in a small, unclear flyout.

02 · Create understanding

Before designing anything, I mapped every factor that actually changes what a send looks like from the outside, across three categories: schedule method (account timezone, contact timezone, a behavior-optimized send time, or throttled sending for IP warmup), content (personalized vs. generic, message length, rendered subject lines, content-block complications), and audience (list size, contacts dropping or unsubscribing mid-send).

Diagram mapping every factor that affects a message send: schedule method, content, and audience, each broken into its specific variables

I mapped the message's own lifecycle the same way, queued, sending, throttled, paused, canceled, or sent (shown above as the cover), since the status UI had to represent every one of those states accurately, not collapse them all into a generic "sending."

03 · Solve for

The table itself dropped the old "Queued" and "Error" statuses in favor of states that map to what a client actually needs to know, with a status indicator built into the column header and warning indicators on rows where a send is failing. Total-sent figures show an audience estimate alongside the running count, since the true audience size can shift while a message is still sending. Status detail surfaces on hover rather than as a separate badge, so the table stays scannable at a glance.

The final Email Sent Messages table: status indicator in the column header, warning icons on failing sends, and audience-estimate totals, with the hover-state legend for each status

The per-message detail view went through its own cuts. Sending rate and estimated end date looked useful on paper, but neither could be solved for reliably, so both were cut in favor of a simpler run-time figure that still bridges the gap without promising precision the system couldn't back up. The "queued" state stayed, so upcoming sends are still visible before they start. A dynamic status banner distinguishes a healthy send from one with a problem, and pause/cancel sit right alongside the link back to the message itself, instead of requiring a trip to a different screen.

The final message-detail modal: send time, total sent against an audience estimate, run time, status, a throttled-sends table, and pause/cancel actions alongside a link back to the message

04 · Validate direction

I reviewed the direction live with the Cordial team in a working session, not just async comments, so ambiguity got resolved in the room instead of over a week of back-and-forth. Feedback favored actual numbers over percentage bars, wanted an audit trail showing who paused or cancelled a message, and flagged that a raw sending-rate metric might itself generate new support questions, a tradeoff that shaped the final copy and layout.

05 · Outcome

The initiative reduced support inquiries and increased user trust, giving clients a more intuitive, self-service way to make informed decisions about in-flight sends.