The quest to curtail email littering

Plato had a theory where he imagined everything in the world was a reflection of a perfect Form. His famous Cave was filled with these Forms, reflected imperfectly in firelight. The perfect chair, the perfect table, the perfect bowl. In Plato’s mind, every person who built a chair was drawing from the perfect Form of a chair as they worked.

If Plato created his Cave today, somewhere deep inside there'd be a box labeled “Perfect product emails.” As we build products, we’re all striving to hit that perfect product email sweet spot with our customers. Our goal is to keep people perfectly engaged while balancing notifications in the Goldilocks zone and nailing every step of the customer journey.

It’s a lofty goal. However, no matter how much time we spend thinking through and designing those emails there’ll always be ways to improve them. Whether you’re starting out with emails for a new app, or thinking through how to improve your product’s existing email, it’s important we all do our part to reduce email littering.

Email littering happens when a message doesn’t add value to an experience. Even if you’ve never called it email littering, you’re familiar with how these emails look. Your inbox fills up with messages from apps and companies who can send you email. Some of these messages are valuable, while others ask for your time and waste it.

A valuable email gets you information you need to know in a way that’s easy for you to read and use. If messages don’t deliver this kind of value, overall email engagement goes down as people set up rules to filter out those emails, or just delete them altogether.

These little signals have a big impact on your delivery. So how can we do cut down on email litter from our products?

Question every email you send #

A great place to start this process is by taking yourself through your notification process. This review is a time to question your assumptions, and make sure you aren’t adding pain to your customers by abusing their inbox. We hit on one simple maxim in our email littering post: only send email your customers want and expect. It’s a great compass to use every time you send an email, whether it’s a marketing blast or a triggered message.

Garrett distilled it into a couple of questions to ask before anyone sends an email from their product.

• “Does the recipient expect this message?” If you can say yes to this question, give yourself a +1.
• “Would the recipient thank me for sending this email?” +1 if the answer is yes here too.

If an email scores a two it’s a good idea to invest time in it and ask for your customer’s attention. When an email only scores one think twice, and if you aren’t saying yes to either of these questions you probably don’t want to send that email. We use these questions as little safety checks to make sure we aren’t firing off useless messages. Even when asking these questions, you’ll still need to use your judgment on what your users expect.

Give your customers control #

Email notifications are one way to keep a user in touch with what’s happening in your product. “Notification email” almost feels like a dirty word, a type of email someone has to manage instead of value. Balancing the scales between informative and overwhelming is tricky. It shouldn’t be this way, but part of the reason so many of us dread these emails is because they fill up our inbox without telling us anything we want to know. 

I mean, it’s cool when someone from high school likes a picture of my kid on Facebook, but I don’t need an email telling me about it. 

There are a few models for how a product can use notification emails, and one is to give customers the ability to keep track of every little action with an email notification. Facebook and Twitter are good examples of this method, but they aren’t alone. Sites that use this kitchen sink type of model give you a big list of notifications to manage in their app. Here’s an example from Facebook. I snagged this image from my account, where I’ve disabled every email notification option.

Twitter takes a different approach and groups your notification choices together by type. They give you a bit of extra contextual info, but the list isn’t as scannable as what you find on Facebook.

Instead of giving users a list of comprehensive options, most apps give you a few notification options. Buffer is a great example of an email notification system focused on getting their customers helpful information when it's needed. They let customers select which triggered notifications they’d like to receive, and the options are clear and concise. The beautiful thing about this method is as a Buffer customer, I don’t need to guess which email I want to turn off to stop certain emails by picking from a huge list.

Here are the default notifications that Buffer uses:

The update failure and success emails are the most likely to generate a low-value email in my inbox. They’re turned off by default, but I imagine many Buffer power users really want to get these updates. 

Another great aspect of their approach is every email type has a clear explanation of when I should expect an email if I turn on a notification. They also avoid nesting options around the kinds of emails you’d like to receive. Those nested options on Twitter take a lot of guessing to figure out which option turns off what email.

Moving beyond managing notification options, you can include contextual info in each message you send too. Basecamp makes it easy to unsubscribe to any message type with a link in their emails, and Github shows recipients why they’re receiving each message. Github includes another bit of contextual info. Each notification comes from an email address specific to the message type, so if someone mentions you in a comment, the email comes from mention@noreply.github.com.

Be judicious with opt-in #

It’s tempting to view someone signing up for our products as a license to send them email. There are emails your customers want to get, like receipts or renewal reminders. Other emails require a bit of examination before deciding whether or not we should opt people into them.

The big question here is if users would find a specific email valuable. If someone didn’t get this email would it interrupt their workflow? What impact would missing this email have on their team?

An example of where we asked ourselves these questions at Wildbit comes from our Code Review feature in Beanstalk. We spent a ton of time researching how teams reviewed code. During this process, we saw it was important reviewers know when someone asked for a review. Once the review is done, the person who asked for the review needs to know it’s done.

Not sending these emails would create a communication void during the review process. For that reason, each one of these roles are opted-in to code review updates on Beanstalk. These messages only get sent to code review participants and aren’t sent to anyone else on the team by default.

If you’re opting people into an email, it’s nice to tell your customers that in your UI. When you opt people into a message, it’s a good idea to help the recipient remember the context. You don’t want anyone to scratch their head when they open these.

Batch send notifications when you can #

The team at Wildbit ran into this particular issue recently as we started using Paper. It’s a fantastic tool for collaborating with text, and we love it, but their email notifications caused most of us to create filters to manage them. Everyone following a document gets a notification anytime someone makes an edit or leaves a comment. These notifications have cluttered our inbox with chunks of emails about changes. 

There’s nothing wrong with the content of the notifications. Everything is well designed and informative in the email. It’s really about how often these updates roll in as we’re working together on documents. 

To the Paper team’s credit, they’ve reached out to us and asked for our thoughts on their app. During those discussions, we shared our notification fatigue with them. As we talked, they shared they are working on improvements to their email notifications.

This a problem we’ve thought through for our products too, and the best example comes from Code Review on Beanstalk. One of the important things we realized for those notifications emails were people made lots of changes in a short period. They might comment on a line of code or point out an issue several times over the course of a few minutes as they reviewed code. Instead of emailing for every comment or interaction, everyone involved actively in a code review gets an email with changes and suggestions chunked together every five minutes.

Consider the context #

Activity summaries can be a helpful resource for your customers. It gives them a snapshot of how they’ve been using your product, but it’s important to think through how these updates work after a period of inactivity. Repeating an activity summary with a big zero doesn’t help your customer.

We’ve applied this principle with Postmark’s weekly email activity summary. This is a very basic snapshot with info on the number of emails sent, which email signatures you used, and a summary of the email addresses you used. If there’s a week when your server doesn’t send any email, we send one follow up summary. After that, you won’t receive any more summary emails until you send another email through Postmark.

Every improvement adds up #

Improving how our apps use email is a flat circle where we create, test, measure, and iterate over and over again. This might feel like pushing a boulder up an endless hill, but it pays off. Over time, your attention to detail adds up, and your customers will notice it. Their recognition translates to higher engagement with your emails and improves your sending reputation. No one may come out and thank you for the work you’ve put into email, but they‘ll see your focus on delivering value make their lives a little easier.