MailerOne: Designing AI-assisted email creation for an email marketing platform.
| Company | Sapmen C |
| Role | UI Design Intern — sole designer on this module |
| Timeline | March – August 2025 (6 months) |
| My scope | Templates module, AI email flow |
| Status | Live — shipped to production |
Overview
MailerOne is an email marketing platform that enables businesses to design, manage, and analyze email campaigns at scale. It combines template management, audience segmentation, campaign analytics, and AI-assisted content generation into a single workflow.
Challenge
MailerOne already had an established design system and product direction. My responsibility was to translate product requirements into production ready interfaces while maintaining consistency across the platform.
Workflow
Templates module
I designed a persistent two-pane layout that let marketers browse, compare, and preview templates while keeping the editor one click away. Keeping both views visible reduced unnecessary navigation and made it easier to work across large template libraries.
Common actions such as renaming, duplicating, and deleting templates were kept lightweight, while destructive actions required confirmation to prevent accidental data loss. Campaign analytics remained attached to each template instead of a separate dashboard, allowing marketers to review performance where decisions were made. Operational settings like subject lines, audience segments, and metadata were separated from content editing to keep the workspace organized.
Designing AI-assisted email generation for marketers
To help marketers draft campaign emails faster, I designed an AI-assisted generation flow directly inside the editor. Instead of treating AI as a separate tool, the experience kept users within their existing workflow while giving them full control over the generated content.
Entry point
The "Generate With AI" button sits in the editor toolbar, so users don't need to find a separate AI section or switch context.
Prompting
Clicking opens the "Magic by AI" modal, large top preview, bottom prompt ("Type your idea… we'll draft your mail."), and visible credit balance and cost before committing..
Generation feedback
The user types a plain language description. A loader appears while the AI works. The credit usage bar updates to show consumption.
Review before insert
The AI outputs a full marketing email (subject, body, images, CTA) and shows three actions—Regenerate, New Prompt, Insert—ensuring users can revise or replace the output.
Continue editing
Insert places the generated template into the editor (full toolbar enabled), so the AI output becomes an editable draft the user can rewrite and own.
Edge case: credits exhausted
When a user runs out of credits, the modal surfaces a clear message with a "Purchase Credits" button. The credit usage bar reinforces consumption. The flow doesn't dead-end instead it routes them toward buying more.
The decision I lost
I designed the email scheduler with an enable/disable toggle. My reasoning: users should consciously opt into scheduling. Let them decide. Let the interface be transparent about what's happening.
The founder pushed back. His intent is to make users use this feature. If scheduling is opt-in, most users will never use the toggle and try the feature and the platform's value sits unused.
I removed the toggle and the scheduler shipped default-on.
Enable/disable toggle. User opts in consciously. Respects autonomy but risks the feature going unnoticed.
Feature on by default. No toggle. It's part of the workflow, always visible, always active. The feature becomes the experience, not an option within it.
The hardest part of this project wasn't any single screen or interaction, it was making the case for conscious user control and losing that argument.
Reflection
I had a principle I believed in but it differed with the business goals
The toggle story is the thing I keep thinking about. Not because the founder was wrong if a feature genuinely helps users and nobody uses it because it's hidden behind a toggle, then its redundant. Sometimes removing an option is the design decision.
The lesson wasn't that my design was wrong it was that I defended a principle instead of reframing it around the product goal. I argued for user autonomy, while the product was optimizing for feature adoption. Next time, I'd explore solutions that satisfies both.
What I've learned
I'd look for a middle ground before defending a single solution. Instead of arguing for a visible enable/disable toggle, I could have proposed a default-on experience with an opt-out in settings & balancing feature adoption with user control. I learned that product design isn't about winning arguments; it's about finding solutions that satisfy both business goals and user needs.