Ever since Dr. Dre dropped "2001" in 1999, designing and building HTML emails (or "eDMs") has been a reliably painful recurring task for both designers and developers.
Spending days writing HTML that's straight outta 1995 and fighting with Outlook bugs, all while the original "approved" design simultaneously going through countless rounds of reviews and visual/content changes that then need to be manually updated again in the HTML — it's enough to make any designer or developer slowly lose their mind.
That's why today, after over a year under development and throwing out our first two approaches to solving the problem, we're excited to release our brand new Figma plugin — Emailify — which helps you design and automatically export responsive, production-ready HTML emails (in seconds) without leaving Figma.
To accompany the release, I'd like to go through some observations, thoughts and insights into some (personal) history of "the email problem" and how we went about building a Figma plugin to help solve it for both designers and developers.
Designers use Figma, not MailChimp
Working in digital agencies for a decade, and being involved in (literally) hundreds of email marketing projects, and without exception, designers used their usual software of choice (Photoshop, Sketch, Figma etc) to design the email; which means they were not using the "email designer" tools provided by email service providers like MailChimp, Campaign Monitor etc.
This observation is not a slant against those great companies or the tool they provide, but an underlying truth about how designers actually design marketing emails for their brand (or their client's brand) in reality.
Despite the reality of designers using Figma to design their emails, and developers working outside Figma to build them, little progress has been made to connect popular design tools and production-ready HTML.
If designers are using the design tools that they use for designing everything else (websites, banners, apps, presentations etc) to design emails, then it's worth thinking about how these designs are then make the leap from screen design tool (pixels) to code (HTML).
Considering how regularly these kinds of projects are being done by design and development teams, it's surprising that these two halves of designing and building HTML emails couldn't be more disconnected.
Removing the designer/developer "hand-off" feedback loop
One of the key problems to solve with the HTML email problem is the completely disconnected nature of designing and building emails, where the pain is felt more intensely with increasing rounds of changes after the development has already been given the go ahead to start.
Trying to keep the development side in sync with design (even while working in an awesome collaborative tool like Figma) is extremely difficult, as it's not only hard enough to keep track of what changes have actually happened, but actioning those changes can totally change how you originally structured the original code.
Co-ordination problems aside, once a developer knows what parts of the design need to be updated in code, it still involves them manually re-exporting images, extracting HEX codes for colour updates, copying and formatting text and content; this is all the easy stuff, that doesn't involve changing the actual layout itself.
Once you understand that each round of changes not only takes a bunch of time doing very manually copy/pasting type work, it also increases the chance of re-introding brand new visual bugs (in email clients) that may have just been resolved after the last round of updates.
Emailify solves this problem by adhering to one of our core principles:
The distance between design and production should be zero.
The shortest distance between design and production is not "bridging the gap"; the gap has already been "bridged" to some extent, but it still largely involves all of the overhead and headaches described above. By allowing anybody (designers, developers, copywriters, project managers etc) to export an Emailify email design in Figma to HTML with one click, all of the concerns above disappear.
Attempting to build an HTML email Figma plugin (3 different times...)
It was almost 18 months between starting to work on the idea of building a Figma plugin to help with HTML emails and actually shipping the first release. It's not that the actual build took over a year, but the direction and core approach of the plugin changed a bunch over the course of that time; resulting in 2 totally scrapped plugins, and eventually leading to the 3rd attempt that was published as the first public version.
Attempt #1: Computer Driven
Back in September 2019, the very first version (of what would eventually become Emailify) was a somewhat naive attempt at creating a totally magical plugin where you could literally click a single "Export HTML email from Figma design" button, and the plugin would somehow take care of the rest. Believing this was very possible, I spent a couple of months working on a plugin that would do this. The plugin kind of worked, and included on early (and obvious in retrospect) learnings like correctly ordering the elements in the design by their position instead of relying purely on layer order, but working out basic things like this was only the tip of the iceberg.
As soon as basic layout is working fairly well, you quickly run into questions of "intent" on the part of the designer. When you're working in code for a Figma plugin, knowing about a series of rectangles places in different positions on a page doesn't really provide you with much information about what the designer intends those rectangles to be. For example, is a rectangle with some text on top of it intended to be the visual representation of a row, a column, a hero banner, a lockup that should be "merged" into a single image or something entirely different?
This gets way more complicated when it comes to responsive design. Typically (partly because there's no really good alternative) to do this, designers tend to design a "desktop" and "mobile" version of an email by creating two totally different frames which share the same (hopefully) content, just resized to fit the narrower frame size. From the perspective of a plugin, now looking at 2 totally seperate frames with somewhat similar content, which may or may not be in a similar order or contain similar layer names, it becomes even harder to reconcile these two things.
Do you reference one as the source of truth, and try to match up layers to parse the "responsive intent" of a designer? Do you force the designer to name layers exactly the same thing to make it more reliable? These are all really bad options, and the benefits of what the plugin was meant to offer start breaking down really quickly.
This attempt was essentially scrapped, as attempt #2 would soon take its place.
Attempt #2: Human Driven
With attempt #1 hitting a dead end, a few months later led to attempt #2. Based on some of the learnings from the first attempt, I went the other extreme and decided to try and approach where the plugin would actually come with "intent" out of the box.
Not wanting to leave anything in the hands of the computer, this approach was very much a human-driven plugin. Designers would have to select from a handful of super primitive layout and content objects (rows, columns, text, image, button) and then put all of these pieces together in their own fashion to try creating something that then looked like an email.
While it probably would have "worked", it felt way too restrictive, abstract, unnatural, and maybe most importantly not fun or very enjoyable to use. Once again, this attempt was scrapped; until attempt #3 would see Emailify actually see the light of day...
Attempt #3: Human-Computer Hybrid
With these first 2 approaches, I had tried 2 different extremes: total computer automation and total human creation. Neither of these approaches make sense.
For attempt #3, I went back to our own vision of what we're trying to do:
Our premium Figma plugins complement your human creativity with computer automation to 1000x your workflows
We want to empower designers and developers to be creative in ways that are best done by humans (design), and then complement that with automation with the parts that make more sense to be handled by a computer (generating code). This hybrid model drives most of our other Figma plugins, and I believe it's the key to furthering real productivity gains for designers and developers.
Learning from the first 2 attempts, it seemed like the best way to divide the tasks between humans and computers would be to give the computer the parts that could be totally automated: creating the basic structure, layout and content modules on the Figma canvas, and exporting a design to HTML. The human side would involve things that humans are better than computers at: making design decisions and crafting an email that meets their creative brief.
These two skill-sets are almost perfectly complementary: it allows a designer to maximise their creative time without having to manually draw and configure basic modules before they can actually bring them to life with content, and it allows anybody to export that design to HTML with one-click; completely saving a developer's time (who really does not want to be writing HTML tables from 1995 and wrestling with Outlook bugs) and allowing them to also have their own time given back to them for working on more interesting pursuits.
Of course, this is just one approach to solving the problem, but after exploring these different ideas, the human-computer hybrid approach is the one we believe to be the best for this type of work.
What's next from here?
Now that the third approach to building the plugin has been shipped, it serves as a great foundation to be able to continue adding more value and efficiency benefits to designers and developers using it to design and build HTML emails with Figma.
The way the plugin works and how it was built means that we can continue adding more common modules to help speed up the initial layout design process, and reduce the amount of guessing work for constructing common email components.
At a layer above the modules, this means that fully Emailify compatible templates can be designed and shared at companies internally, but also shared with the Figma Community at large. This would be a massive timer saver in both cases, and it's easy to imagine how these templates would play nicely with other Figma plugins that could provide a way to easily roll out multiple variations of a single email template within seconds - then exported from Figma to HTML within seconds after that.
It's still super early, but we're really excited to continue improving Emailify and the ecosystem around it, with the mission of evaporating the familiar pains of designing and building HTML emails into a distant memory.
