My Email Workflow: From Sketch to Send (Planning, Coding, Testing)
One of the first emails I ever coded broke spectacularly in Outlook. The button disappeared. The text shifted. The padding collapsed. I had tested it in my browser, but not in the actual inboxes where it mattered. That was the day I stopped winging it and built a real workflow.
Now, every email I send goes through a structured process, from early sketches and strategy sessions to coded layouts, responsive checks, accessibility tweaks, and full inbox testing.
This is my exact email workflow, the one that keeps things stable, scalable, and inbox-proof.
Step 1: Define the Purpose
No code. No comps. Just clarity.
Every good email starts with a simple question: What is this email trying to do?
Is it:
Welcoming a new subscriber?
Promoting a product?
Triggering a post-purchase message?
Driving traffic to an event or blog?
I write a 1–2 sentence summary of the email’s purpose. That becomes my north star throughout the build.
Step 2: Sketch the Structure
I don’t open Figma or Photoshop yet. I start with boxes. On paper. A whiteboard. Or even a text outline:
Header image
Intro text (2 lines max)
Call-to-action (CTA)
Supporting block or testimonial
Footer with contact and unsubscribe
This helps me focus on hierarchy and clarity, not color or decoration. I can already hear where the design wants to go.
Step 3: Design in Figma or Sketch
Once I know the structure, I mock it up. My design file is simple, clean, and coded with spacing notes. I often create:
A desktop view (~600px wide)
A mobile stacked version (~360px wide)
I also check:
Contrast ratios
Font choices with system fallback
Visual hierarchy for skim-readers
Bonus: I export optimized assets early, no giant retina PNGs sneaking in.
Step 4: Start the HTML with a Clean Foundation
I use a simple boilerplate: table-based layout, inline styles, and bulletproof button code. Here’s the starter block I reuse:
I inline styles manually or use a tool like Maizzle or Premailer if I’m batch-processing.
Step 5: Make It Responsive
Emails must work on mobile, no excuses. I use mobile-first media queries to stack columns, enlarge text, and ensure CTA buttons are tappable.
I avoid:
Absolute widths
Fixed-height containers
Tiny text (under 14px)
And I test it with actual pinch-and-zoom in Gmail and Apple Mail on mobile.
Step 6: Add Accessibility & Fallbacks
Alt text: Every image gets it
Readable line height: ~1.5–1.6
Dark mode safe colors: No ghost logos or invisible text
Semantic tags: Use <h1>, <p>, <ul> where possible
I also make sure the email still looks good in:
Plaintext preview (fallback version)
With images off
Step 7: Test Across Clients
Now the scary part: the email gauntlet.
I test in:
Gmail (web + app)
Apple Mail (light and dark)
Outlook 2016 and Outlook.com
Yahoo Mail
Samsung Email
I use Litmus when needed, but I also send real test emails to my inboxes. I check on desktop, phone, tablet. I break it on purpose.
Step 8: Final Send Checklist
✅ Alt text present and descriptive
✅ CTA works and links tracked
✅ Mobile view stacks properly
✅ Footer is legally compliant
✅ No leftover lorem ipsum or placeholder content
✅ From name, subject line, and preview text are intentional
Once this is locked, I push it through the ESP (Mailchimp, Klaviyo, or a custom SMTP setup), do a final pre-flight check, and schedule or hit send.
Final Thought: Build a Process You Can Trust
This workflow didn’t show up all at once. It came from mistakes, like broken Outlook buttons or mobile layouts that failed in the wild. But now it works. It keeps me sane. It keeps the work clean. And it keeps the message front and center, where it belongs.
Still thinking it through? Contact me here and I’ll help you get it right.