From approved design to working email

By Gyata Tabiri · Revised November 2, 2026

When a team brings me an approved email design, the assignment is often to build it, not redesign it. The judgment comes in recognizing which details will carry through and which need a conversation before they become a problem.

Where judgment enters the build

I have occasionally received designs that needed adjustment around layout, mobile stacking, background images, or buttons and interactive effects. Those are the moments when coding and design need another conversation. A detail that works in a mockup may need a different treatment in an email client.

Make the problem visible

I have used written explanations, screenshots, and conversations to show the issue. The designer then revised the design. That exchange gives the change a reason: which part is affected, why it needs attention, and what needs to remain recognizable. It also keeps a technical fix from quietly becoming an unapproved redesign.

Test the revision

Depending on the company, I have used Litmus or Email on Acid, alongside Apple Mail/iPhone Mail. The testing scope depends on the assignment. The useful record is the version tested, the environments checked, the issues found, and the decisions the team accepted.

What the team gets

A good handoff preserves the thinking as well as the file. Notes about a fallback or an accepted difference help the next person maintain the email. This is one way my background in both design and development contributes to a focused coding assignment.

The value of that exchange is a design revision everyone understands and a build the next person can maintain. It brings the visual intention and the implementation into the same conversation.

The decision: preserve the intention, discuss the implementation

A background image or carefully positioned button may be central to the design. I would first identify what that detail is doing for the message, then discuss an implementation that can preserve its purpose in the required clients. A technical limitation is a reason to show the designer the problem and agree on an alternative. It is not permission to quietly change the approved work.

Review the representative My Little Pony build alongside the case account. The file shows implementation choices; it does not establish how every inbox rendered it.

My Little Pony email work · Discuss a role or project