Modular email design: A new philosophy that changes the email design experience

23 June 2023

Modular email design is transforming the landscape of email marketing. But modules are way more than just perfectly designed email snippets. This new approach to the modules and email production, as a result, will totally reshape the workflow within email marketing teams, enabling marketers to focus more on strategy than on technical details.

Module library over templates library

Email turns 50 this year, and over this period, it has evolved from a plain-text format into a dynamic one. Over the years, there have been numerous approaches to email production, including plain text, HTML coding, WYSIWYG editors, drag-and-drop builders, prebuilt templates, and the modular email design itself.

Today the world is still in the “Prebuilt templates” phase. Most tools even boast about their number of templates, describing it as one of their most valuable features.  However, a template is just a marketing trick and not a real saver for email marketers.

No matter how many templates an email design software has, you only have to choose one of them. And then work on it, and with it — you modify its content from campaign to campaign, etc. But what if you want to change the structure of the template or alter some elements? You need to restructure and modify the entire template.

As for the module, it is an independent content unit; its design and content are brand consistent but have a unique structure, unique content, and, more importantly, its purpose. So you can easily combine them. This is why software tools actually should brag about theirmodule library, where all the modules are independent.

Luckily, today, the world is slowly transitioning from the templates stage to the modular email design stage.

State of modular email design today

Firstly, it is worth mentioning that the “modular email design” may also be referred to as “modular email architecture” or simply “modules.” So, you can come across any of these terms online.

Today, in fact, many CDPs/ESPs and email builders support modules. Most see it as saving and reusing the most frequently used email elements across future email campaigns. This approach gives us the following advantages:

  • Easy to maintain brand consistency
  • Email production becomes time- and cost-effective
  • Simplified design process
  • No need to run email tests that often
  • Hassle-free last-moment changes

And all this is correct, but to me, a modular email design is about much more than just dragging prebuilt email elements. It goes a step further.

One step further: Modules+

I see a module as a content unit where the design can be dissociated from the data, I call it “Modules+.” This is the essence of the modular email architecture, and this is what makes it a new philosophy that fundamentally transforms the email production experience.

What does “data dissociated from the design” mean?

It means that you can optimize, change, edit, and modify the design of the module the way you like, and this will not affect the data in this unit. Or you can build a wireframe of a certain email section/module, set its structure, assign a location and dimensions for each element inside this module, and then update only dynamical content, i.e., data. The latter will inherit all design styles that were previously set for this particular module.

What problem do they solve?

Gamification in emails, which is a trend now, abandoned cart emails or any other emails with dynamic and interactive content, require coding. In order to create such content for newsletters, email marketers need to either learn to code (which is not what they are supposed to do, I’d rather they focus on marketing) or ask developers for help anytime they initiate a new campaign or need to make the smallest change to the email’s, as it is closely tied to the data.

With the modules+, which allows the design to be separated from the data, we finally enable email marketers to work on the design independently. This saves both marketers and developers a significant amount of time, even when making bulk updates to the design of the modules without affecting data.

To empower email marketers and make them self-reliant, modern email building software (some already have this capability) should prioritize automating the process of pulling data into emails. This can be achieved through links, variables, and other means. Essentially coders and developers would set up this functionality just once. Then the email marketer can independently just update/replace this data with the necessary one without dealing with the code or even automatically.

This will result in totally new flows inside email marketing teams.

Benefits the modules+ bring us

  • You can “lock” the design. Meaning once you’ve built a wireframe, its design styles, including the number of images and their location, cannot be altered when you update the data in the module;
  • You can create modules with Smart elements and “lock” the data. Meaning you can affect the colors of the buttons, font size, and color, but you cannot modify what data that gets pulled into the module via a link;
  • You can pull in the data via a link or a variable into your modules, as in abandoned cart emails, automatically;
  • You can bulk update the design or data in your modules by modifying only one once they are synchronized. Meaning you can automatically update all existing emails by modifying one single module;
  • You can create complex modules with AMP content, its HTML and text fallbacks, and let email marketers deal with the visual elements through UI, not dealing with data. You can generate these modules with Stripo, and use them in your tool because the modules are compatible with any email builder and ESP that have support for AMP.

Key takeaways

I believe that coding emails is not something that marketers should do. They should focus on marketing strategies instead. And this is where the modular email design comes to the rescue.

  1. Module library goes before template library
  2. Design must be dissociated from data in modules
  3. Modules should be synchronized for bulk editing
  4. We need to automate the ways to pull data into the modules

Dmitry Kudrenko
Founder & CEO of Stripo