Our first redesign (Part 1)

Our first redesign (Part 1)

Our first redesign (Part 1)

TLDR: We’re launching the first large-scale design update of Loops.

It started with a limited product, which was inherently tied to a simple design. The real challenge began after we scaled the complexity of the design system and the capabilities of the platform. This is the brief story of the Loops redesign.

Our first bit of code made it into production for users during Y Combinator, in Winter 22. The app looked somewhat like our wireframes and mostly met our MVP for what a user might want to see when they click into the platform.

Something simple, that felt like an easy way to get from A to B, without the clutter of other email-sending platforms. Simplicity would be our unshakeable differentiator!

Of course, that’s the secret of most early-stage products, simplicity is inherent because you haven’t built much yet.

“The clutter” that occurs is often the result of building many imperfect features over time, it’s much easier to not have any clutter when you’re only building an app to accomplish a single action.

Anyway, here is the wireframe. Ladies and gentlemen, a table.

Then we immediately changed the design.

We added emojis, yes emojis, because they’re actually an easy way of adding status indicators and users are familiar with them.

We also created large, padded cards users could click.

Now you could create one email and boom, a 1/5 of the screen was utilized, suddenly our app didn't feel so empty. We wanted to make it easy for users when they log in. Ideally, they see a big button for their last Campaign and click it.

This was a sufficient dashboard for us and we went live to a waitlisted group of users.

FYI this is weird frankenstein's monster version pulled from the archives but you get the gist

A few months into the company, we were pleasantly surprised at the largely positive feedback around the UX.

I learned quickly that one of the remarkable aspects of early stage building is you have frustrated, senior people in positions of (purchasing) power within their company.

Those buyers may choose to use your silly new piece of software because they’re fed up with the incumbents.

Collect enough of those Initial Angry Users, you may even have the start of a business.

But, eventually, you do have to do something beyond being ridiculously simple to use and not one of the established players.

To get there, we spoke with more users and we kept building.

First, we added our automations feature so users could send onboarding email to users as they joined. We uh, called those Loops.

Quick aside:

In retrospect, naming a key feature of your platform the same thing as your brand is not a brilliant tactical decision. Imagine adding a new Rippling in your Rippling dashboard or a new Linear in your Linear workspace. Not great.

Anyway, after that questionable naming decision, we had two things! Campaigns, batch emails, and Loops, automated emails.

And then, of course, users started to get confused because now there were two things.

There goes the simple value prop of only doing one thing.

Our solution was to make it easy to utilize those products, so we gave users a starting point and offered Templates.

We hired a talented copywriting person to write them and then I rewrote them several times after paying the invoice, and now they’re probably due for a rewrite but they’re in the app! Users were again happy, but the visual clutter increased.

And it would keep increasing and our large padded card format had started to fail us.

Our long-term vision was always one platform to rule them all (for email), and one of our larger clients (shout out to Framer!) started to call our bluff.

We needed to add Transactional email in order to fulfill the mission statement.


And that’s another product added!

Thankfully, we mostly had the rails in place to build that out, so we crafted an excellent dev experience (easy install with npm i loops), documented the feature in our docs and most importantly of course, added it to the Home screen.

And of course, it needed it’s own set of templates, so those were added as well.

And now we have our current Home page, that is filled with big bubbly cards that are not keyboard selectable, not sortable and cause the user to scroll forever to get to the bottom of anywhere.

Plus, Transactional email isn’t even visible on this page without scrolling, much less the templates.

Not great, Bob.

Now that users were using the platform, we had to revisit how the platform was laid out based on the new features and paths users were taking.

We have users from the alpha stage who have accumulated years of emails with no sorting options.

The basic requirements we came up with for the new design:

  • Keyboard navigable

  • Fully responsive

  • Limit scrolling

  • Standardize typography

  • Deemphasize the emojis

  • Actual sorting by last updated, sent, etc

  • Drag and drop should still work for manual sorting

  • Preview templates before creation

  • About a dozen other small issues that nobody noticed but drove me up the wall*

*Did you know emojis are different sizes on Chrome vs Safari vs Firefox due to native font handling regardless of the size you give them? Terrible.

And that’s how we ended up with our latest set of designs.

It took about 3 months of casual back and forth and uh about 300 Figma mockups plus a dozen branches I deleted before we landed on something we liked.

We hope you like it too, it’s available now for all users.

This is Part 1 of 3 of our redesign. Our app is divided up into a few major parts:

  • Onboarding: Creating an account

  • Browse: Finding your emails

  • Nav: Get around the app

  • Write: Create an email in the app

  • Build: Craft a Loop

  • DevEx: Transactional and API

  • Settings: The Settings

We worked on Browse and Navigate in this release. Next will be Write, Build and Dev in Part Two followed by Settings and Onboarding in Part 3.

Ready to send better email?

Ready to send better email?

Go