A no-code email builder for marketers

01The problem

FeedOtter is a powerful email automation engine, but its self-serve promise depended on non-technical marketers building and shipping campaigns without a developer. In practice they were blocked: assembling a responsive, on-brand email meant hand-editing HTML, and email rendering is unforgiving. What looks fine in one inbox collapses in another. Marketers filed a ticket to engineering for every template change, which slowed campaigns and buried the eng team in one-off requests.

This was workflow-heavy product work, not a landing page. A user drags in blocks, binds them to a live RSS or data feed, configures responsive behavior, sets brand rules, previews across clients, and schedules a send — a multi-step flow with real system state at every step.

02My role

I led the design of the visual editing experience end to end: the drag-and-drop canvas, the block settings panel, the responsive template system, and the empty, loading, and error states that hold it together. I owned the interaction model and the design decisions; two engineers built it and a PM owned scope. Brand and marketing-site work was handled by others — my surface was the product marketers work inside every day.

03The approach

I started with support-ticket triage and interviews with power users on customer marketing teams. The clearest signal: people did not want a blank canvas, they wanted to start from something safe and edit it. That reframed the product from "design tool" to "guided editor," and it changed what we built first — brand guardrails baked into each block (locked type scales, approved color tokens, constrained layouts) rather than validated after the fact.

The core trade-off was freedom versus safety. Full CSS control tested well with our two most technical customers but produced emails that broke in Outlook, so I cut it from v1 and instead exposed a curated set of controls that map to rendering-safe patterns. I de-scoped a custom-HTML block for the same reason — it undermined the whole guardrail premise. Because email clients strip modern CSS, the responsive system had to degrade predictably, so I designed explicit mobile-stack behavior and accessible defaults — alt-text prompts, minimum tap targets, contrast enforced by the token set — into every block rather than leaving them to the user.

04What I built

I shipped the drag-and-drop editor, the block settings panel, and the responsive template system underneath, plus the feed-binding flow that connects blocks to live content. Engineering constrained us to a rendering engine that could only reliably support a fixed grid, not free-form positioning, so I designed the canvas around snap-to-column blocks instead of absolute drag — negotiating that boundary with the PM and eng lead early rather than fighting the platform. It made the tool more opinionated, which matched what research told us users actually wanted.

I designed the full set of states around the happy path: empty states that seed a starter template, loading and skeleton states while feeds resolve, a broken-feed error that keeps the layout intact instead of blanking the block, and inline validation that warns before a send when an image is missing alt text or a link is empty.

05Outcome

The work moved FeedOtter from a functional utility to a polished self-serve SaaS product. Marketing teams could build and ship responsive, brand-safe emails without touching code, and the volume of template-change tickets to engineering dropped noticeably.

The clearest v1-to-v2 moment came from watching real usage: users kept rebuilding the same layouts from scratch, so for v2 I added saved, reusable brand templates and block presets. Setup for a new campaign fell from most of an afternoon to a few minutes, and customer teams told us they finally trusted the tool to stay on-brand without a designer reviewing every send.

06Reflectionoptional

Cutting custom HTML from v1 was right, but I under-communicated it to the two technical customers who wanted it, and they felt the tool was fighting them. I would have shipped an explicit "advanced mode" placeholder on the roadmap earlier, so the constraint read as a deliberate choice rather than a missing feature.