Skip to main content

Hack project to full-feature: Improving email Layouts

Recently at, we released a Layout Starters feature. What began as a hack project at our recent Iceland retreat grew into a full-fledged piece of product work, along with a new suite of documentation. We’re pretty proud of it and wanted to share!

This post digs into both UX process and front-end, and comes to you from both Ivana and front-end engineer Kate. We’ll show off what we built, what we didn’t, and our plans for the future.

What Was the Problem?

While might seem similar to other email-sending apps, there are a few critical differences, and email layouts are one of those. Because of how we process and send messages, the layouts are decoupled from an email’s actual content, and the two are defined in different places. So you can create one Layout and use it for many emails.

This is what a Layout looks like in

Then, when you write your email’s content in, we package up the entire message: grab the content, grab the layout, grab all the associated data, and put them all together. This ability to use contextual, relevant, recent data in a message is what makes powerful.


It wasn’t easy for our customers to build well-styled emails in all clients. There’s not always a neat line to be drawn between an email’s style and its content. (And we weren’t as helpful as we could be.)

We used to provide auto-generated layouts in every new account:

Then, once users edited those, they couldn’t get them back.

We also gave very little guidance on how to use these. Clicking on” Create Layout” would bring you to a code editor, with little direction as to what to do next. And when folks did make edits to the underlying code, it was easy to break (because HTML and CSS in email is finicky).

So we worked to understand what customers needed at the most basic level (e.g., “I just want a basic structure into which I can add a logo/promo image/company info, and that’s it!”). The goal of our hack project was to make it easy for our customers to send super-basic and nicely-styled emails, with little-to-no layout/code customization. Then, for those who want to edit the code, enable easier customization and ensure less layout breakage.

Kate built a prototype, while Ivana worked on the design of the emails themselves, and we tag-teamed the UX. Whenever a user clicked to create a new email layout in, we presented them with three default layouts to choose from.

But we didn’t want to ship it.

Ultimately, this was a great example of a feature that we could start during hack week, but we needed more time to get right and understand the intricacies. Here’s what we learned:

  1. We were still missing some key information around how customers used Layouts and what they needed from them.
  2. This full-fledged feature work needed a more formal product cycle.

In that first iteration, we were providing the customers with this default collection of elements they may or may not actually use. What they needed wasn’t a set of example layouts, but a template from which to start.

So that’s what we did!

Enter Layout Starters.

From “Default” to “Starter”: Being Confident and Clear

Initially, when we decided to get rid of our auto-populated layouts and provide starter templates, we aimed for clarity and purpose and considered how much coding our customers would need to do. We found ourselves asking:

  • Are these styling suggestions or layout suggestions?
  • How does each starter template differ and support the use-case it suggests?
  • Where does the content go?

To eliminate these points of confusion, this is what we made:

We modified and simplified the collection of starters and their layout on the page to answer the questions.

Are these styling suggestions or layout suggestions? By removing visuals completely, we took a clear stance on Starters’ purpose: we will make it easy to arrange elements, not “design” them. We expect and encourage customers to add their own style to these!

How does each starter template differ and support the use-case it suggests? Presenting the templates in a masonry-style layout allowed us to display the full height of each starter and makes their differences clear. Furthermore, the user is no longer distracted by the varying styles of each template and can instead focus on the positioning alone.

Where does the content go? Replacing the tiny {{content}} text with a large placeholder image in the preview cards makes it far clearer that the user’s content will be surrounded by the wrapper that a Layout provides.

Iteration & Feedback

Once we decided that Starters were how we wanted to move forward, it was then a matter of refining the user experience around them:

  • What should the empty state look like — when a user first arrives to the Layouts area of the app?
  • What exactly should the steps of creation be — separate pages, a modal, or a mix of both?
  • Until customers have created their first Layout, what should we use for their emails?
  • How do we give customers confidence to make changes to these?
  • How do we measure the success of the feature? How do we gather feedback?
  • Copy refinements: How do we describe each starter and what it does?

And last but not least, documentation: Layout Starters were a feature on their own, but they had far-reaching consequences into messaging and how the rest of would work. How do we make customers aware of the change, and empower them to use it?

We tinkered, iterated, tested, and continually asked for feedback and input from the team. And by the end of the product cycle, we had our first version of Layout Starters that we shipped to customers.

What We Shipped

Now, when a new customer arrives to Email Layouts in, this is what they see:

We tell them that they haven’t created a custom layout yet. Technically, there is one Layout in the background — an empty one that we use for emails that are currently going out.

Then, when the user clicks Create:

Five Layout Starters + “Start from Scratch”

Each starter has a defined content arrangement suited to a specific use case, as well as a description:

We used the three we originally started with, but also added a “Basic” option in response to feedback. Basic isn’t empty, nor is it a Layout: it’s some simple skeleton code which ensures that text and images will maintain reasonable widths across devices and clients (especially for plainer-style emails that mimic messages you write in your personal email client).

Foundation & Litmus

Layouts will require customization with HTML and CSS. Rather than getting around that, we tried to make it as easy as possible by utilizing a tried-and-tested framework for emails (Foundation), and testing the daylights out of our code in Litmus.

Code Comments and Documentation

Documentation is just as much a part of the product as the feature itself; this was especially the case for something like Starters, which necessitated some HTML and CSS savvy from customers. We decided to leverage that.

When customers look at the code and start to customize it, we’ve added comments in order to help them find their way:

These, along with documentation guides and a small library of code components, make it easier for folks new to HTML and CSS to copy and paste basic components (“I just want to add my logo, nothing else”), while not taking more powerful functionality away from those comfortable with email code.

In our Knowledge Base, we wrote some extensive guides and provided copy-paste guidance on how to:

  • change up logos
  • change colours and typefaces
  • add basic grids
  • add buttons and menu links

…all easy, basic changes that customers would expect to make, made accessible and consistent.

Overall, we shipped a feature that is a little more technical than expected and became a little more complicated than expected — after all, originally we’d just wanted to give folks some nice basic default layouts to start with.

But after understanding the intersection of both what our customers wanted and what our platform could support, we came up with something great. And it all started as a two-day hack project!